Components: Tooltip Memory Leak

[rosslavery]

Bug, feature request, or proposal:

Bug

What is the expected behavior?

For tooltip to not leak memory.

What is the current behavior?

Tooltip seems to leak memory.

What are the steps to reproduce?

Plunker with tooltip:
https://plnkr.co/edit/IFpa3W9EXGG1Mch7TBmm?p=preview

Plunker without tooltip
https://plnkr.co/edit/vFdyEmedUYGCavMl8eEN?p=preview

Which versions of Angular, Material, OS, browsers are affected?

Used plunker template provided in issue template, so latest.

Is there anything else we should know?

I performed a devtools timeline recording and tried to keep it apples-to-apples. I performed GC at the start and end of each recording.

Strangely, both recordings seem to indicate leaking DOM nodes, which aren't cleaned up after a GC. The version with the tooltip however, doesn't clean up after itself nearly as nicely as the version without it.

Timeline Without Tooltip

Timeline With Tooltip

[rosslavery]

Hey guys, any movement on this one? I have an app in production getting killed by this right now.

[andrewseguin]

Working on a PR now that should fix this by removing the logic of dynamically adding/removing the tooltip. Instead it'll sit in the DOM for the life of the host element.

[rosslavery]

@andrewseguin I'm not certain that is the cause, as the leak can be observed without ever actually hovering over the buttons that have the tooltip applied to them. In the plunker, you can run your mouse up and down the left side of the list items, without ever hovering over the buttons on the right that trigger the tooltips to show,

[andrewseguin]

Can you confirm that removing HammerJS from the plunker helps resolve the issue? Looks to me that the CPU usage returns to normal if it's not imported.

[rosslavery]

@andrewseguin I can confirm that removing hammer makes a significant, measurable difference. Removing it fixes the DOM node leaks, cpu usage, and the effectiveness of garbage collection.

With Hammer:

Without Hammer:

Nice find...where do we go from here?

[michastreppel]

The tooltip component starts listening for mouseenter and mouseleave events on construction. When hammerjs is present there will be a reference between the tooltip and hammerjs because of this (see screenshots of the heap snapshots). Due to this reference the tooltip cannot be garbage collected after the destruction of the component and memory will be leaked.

To let the tooltip be garbage collected on destruction either hammerjs should not be used or (preferably) the reference between the tooltip and hammerjs should be removed. Removing the reference is done by stop listening to the mouseenter and mouseleave events when the tooltip is destroyed (see my PR of May 26th).

[rntsn]

Just want to add that this affects md-slide-toggle as well.

[Gil-Epshtain]

I have the same issue (Angular and Material v6.x) and removing HummerJS from my project solve the memory leak in my case. However not I keep getting warning messages in the log:
Could not find HammerJS. Certain Angular Material components may not work correctly. [core.es5.js:170 ]
Hammer.js is not loaded, can not bind 'longpress' event. [core.js:3263]
How can I tell Material I'm not interested in HummerJS any more??? (so I won't see the warnings)

[jo-me]

@mmalerba @andrewseguin Is it possible that the PR did not actually resolve this issue?
I'm on Angular 6.1.4 with Material 6.4.6 and still have tooltip memleak issues..

[liquidcowgithub]

Hey

I'm getting this tooltip memleak issue as well with Angular 6.1.7, Material 6.4.7, and HammerJs 2.0.8.

Profile on Chrome (Version 68.0.3440.106) with HammerJs imported:

Profile on Chrome without HammerJs imported:

Should I open a new issue for this?

[angular-automatic-lock-bot[bot]]

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._}