Skip to content

bug(mat-table): memory leak in mat-table #30453

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
1 task done
lahlers opened this issue Feb 6, 2025 · 2 comments · Fixed by #30461
Closed
1 task done

bug(mat-table): memory leak in mat-table #30453

lahlers opened this issue Feb 6, 2025 · 2 comments · Fixed by #30461
Assignees
@crisbeto
Labels
area: cdk/table P2 The issue is important to a large percentage of users, with a workaround

Comments

@lahlers
Copy link

lahlers commented Feb 6, 2025

Is this a regression?

  • Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

17.3.6

Description

Whenever elements in a mat-table stop becoming visible (for example due to page change with a paginator) the DOM elements stay in memory as detached elements. This only resolves with a page reload.

When checking the retainer on detached table elements it is the StickyStyler.

The behaviour is present since at least version 18.2.8 possibly earlier.
In version 17.3.6 it seems to be working correctly.

Reproduction

StackBlitz link: Stack Blitz from https://material.angular.io/components/table/overview#pagination example
Steps to reproduce:

  1. Change pages via the paginator a few times
  2. Check detached elements

Expected Behavior

DOM elements of the table that are no longer shown should not be retained as detached elements but properly cleaned up.

Actual Behavior

All DOM elements of the table that are no longer visible stay in memory as detached elements until the page is reloaded.

Environment

  • Angular: 19.1.3, 18.2.8
  • CDK/Material: 19.1.3, 18.2.8
  • Browser(s): Firefox, Chrome, Edge
  • Operating System (e.g. Windows, macOS, Ubuntu): Windows, macOs, manjaro Linux
@lahlers lahlers added the needs triage This issue needs to be triaged by the team label Feb 6, 2025
@vhschlenker
Copy link

Using Google Chrome Version 132.0.6834.160 (arm64) on macOS, I can confirm and recreated the problem by just clicking thought the pages in the paginated table on the material components page.
Even after waiting a few minutes and manually calling the GC through the "Performance", the number of detached elements stays the same.
The screenshot shows the initial state after page load and the increasing number of detached elements.

Image Image Image

crisbeto added a commit to crisbeto/material2 that referenced this issue Feb 9, 2025
@crisbeto
fix(cdk/table): memory leak when no rows are sticky
3bce601 
The table has some logic that queues up measurements of rows that will become sticky so that they can be measured once we set up the resize observer. Afterwards the queue is cleared once the measurements are done. angular#29814 introduced a memory leak where the tracking was happening even if the row isn't actually sticky which meant that the resize observer was never set up and the queue kept growing as new rows are rendered.

These changes resolve the leak by only queuing the measurement if it's necessary.

I've also fixed another potential leak where we were setting up the resize observer, but we weren't destroying it.

Fixes angular#30453.
@crisbeto crisbeto mentioned this issue Feb 9, 2025
Merged
@crisbeto crisbeto self-assigned this Feb 9, 2025
@crisbeto crisbeto added P2 The issue is important to a large percentage of users, with a workaround area: cdk/table and removed needs triage This issue needs to be triaged by the team labels Feb 9, 2025
crisbeto added a commit that referenced this issue Feb 10, 2025
@crisbeto
fix(cdk/table): memory leak when no rows are sticky (#30461)
bf94082 
The table has some logic that queues up measurements of rows that will become sticky so that they can be measured once we set up the resize observer. Afterwards the queue is cleared once the measurements are done. #29814 introduced a memory leak where the tracking was happening even if the row isn't actually sticky which meant that the resize observer was never set up and the queue kept growing as new rows are rendered.

These changes resolve the leak by only queuing the measurement if it's necessary.

I've also fixed another potential leak where we were setting up the resize observer, but we weren't destroying it.

Fixes #30453.
crisbeto added a commit that referenced this issue Feb 10, 2025
@crisbeto
fix(cdk/table): memory leak when no rows are sticky (#30461)
45e3e72 
The table has some logic that queues up measurements of rows that will become sticky so that they can be measured once we set up the resize observer. Afterwards the queue is cleared once the measurements are done. #29814 introduced a memory leak where the tracking was happening even if the row isn't actually sticky which meant that the resize observer was never set up and the queue kept growing as new rows are rendered.

These changes resolve the leak by only queuing the measurement if it's necessary.

I've also fixed another potential leak where we were setting up the resize observer, but we weren't destroying it.

Fixes #30453.

(cherry picked from commit bf94082)
@crisbeto crisbeto mentioned this issue Feb 18, 2025
Closed
1 task
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 13, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@crisbeto crisbeto

Labels
area: cdk/table P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(cdk/table): memory leak when no rows are sticky crisbeto/material2
3 participants
@crisbeto @vhschlenker @lahlers