datepicker memory leak

[rudzikdawid]

Reproduction

Steps to reproduce:

1. go to https://material.angular.io/components/datepicker/examples
2. open datepicker and close multiple times
3. each open and close action generate 135KB memory leak.

The more times we open and close datepicker, the more memory are allocated.
Garbage collector does not clear all allocated memory.

Expected Behavior

datepicker without memory leaks

Actual Behavior

memory leaks

Environment

• Angular: 8.2.14, 9.0.0-rc.5
• CDK/Material: 8.2.3, 9.0.0-rc.5
• Browser(s): Chrome 78.0.3904.108
• Operating System: Fedora 31

[rudzikdawid]

related issue: angular/angular#25744

it looks like the biggest leak comes from @angular/animations module
after remove matDatepickerAnimations and rest of "animations" code from datepicker
each open and close action generate only 1.3KB of memory leak.

[crisbeto]

The animations leak is fixed by angular/angular#34409.

[jelbourn]

Closing since this was caused by the framework and because the fix has been merged there.

[rudzikdawid]

it's look like the memory leak still exists.
I built and launched dev-app from 9.0.0-rc.6 tag.
inside DOM the dev-app element has attibute ng-version="9.0.0-rc.7"
Also inside animations-browser.umd.js i see changes from fix angular/angular#34409.
So theoretically fix should work, but still each open and close action generate 130KB memory leak.

[crisbeto]

I can see the memory leak as well so the root cause probably wasn't angular/angular#34409. I spent some more time looking into it and I'm not sure exactly why it's happening, but here are some observations:

1. It only happens for datepickers in popup mode. There's still a smaller leak in dialog mode, but it only ends up leaking one datepicker worth of elements and it doesn't stack up like the current leak.
2. It seems to happen, because in popup mode we detach the overlay and we only dispose of it on destroy, but by that time the elements have leaked out already. If I switch to disposing it on every close, it starts behaving like dialog mode, but this isn't ideal because it breaks the closing animation.
3. The leak seems to be due to the fact that we remove the DOM nodes once the animation has finished here. If I switch it to remove the element immediately, it stops leaking. This is confusing, because I can verify that the callback always fires at the proper time and the elements do get cleaned up. There might be something further down the line that expects the elements to have been removed immediately.