User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

1. On a page including Zone.js (tested with Zone.js 0.10.3 and 0.12.0 (latest version at this time)), for example any angular application.
2. Add an event listener to the visualViewport object (ex: visualViewport.addEventListener('resize', () => {}))
3. Open the Task manager (about:processes) tab and observe the memory consumption of the page
4. Refresh the page a few time

To better observe the issue, the page should use a bit of memory (example: render a large number of DOM nodes, or simply allocate a large Uint8Array).

Minimal example to reproduce: https://fiferox-memory-leak-when-using-zonejs.benoitzugmeyer.repl.co/

Actual results:

The memory used by the page is never reclaimed, the process memory consumption always grows

Expected results:

The memory used by the page is freed across page load.

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Can repro.

Look at "webIsolated=https://benoitzugmeyer.repl.co (pid 25784) " in the attached memory report

Here is a memory profile https://share.firefox.dev/3FB2qjL
I'm attaching the allocation stack of the retained memory.

The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Is there any particular reason to think that the script isn't just keeping these typed array objects alive itself? That would be my suspicion.

(In reply to Kris Maglione [:kmag] from comment #8)

Is there any particular reason to think that the script isn't just keeping these typed array objects alive itself?

The steps to reproduce include reloading the page, so I don't think the script should be able to keep anything alive.

Yeah, I suggested moving this to DOM: Core. We shouldn't keep anything alive from the previous JS realm when reloading a page. That smells like a leak through some DOM object, but sure, could be something else too.

I concur, even if Zone.js is holding a reference to the typed array, it should still be freed after a page load. I could dig into the Zone.js code to pinpoint the code that triggers this memory leak, but I figured that you'd have better ways of investigating this.

Based on cycle collector logs, there is one DOMEventTargetHelper object keeping the previous page alive.
that object has one unknown reference to it.

That DETH's wrapper, which is also alive, tells it is VisualViewport.
https://searchfox.org/mozilla-central/search?q=symbol:F_%3CT_nsGlobalWindowInner%3E_mVisualViewport&redirect=false tells that we never ever release that object so there is a cycle window->visualviewport->wrapper->window

Patch coming

And thanks Benoît, this is an excellent bug report.

Set release status flags based on info from the regressing bug 1357785

Not that it really matters, but I think bug 1551302 is the more specific regressor, because that is where the pref was flipped for this feature.

(In reply to Florian Quèze [:florian] from comment #9)

The steps to reproduce include reloading the page, so I don't think the script should be able to keep anything alive.

Thanks. I missed that part.

https://hg.mozilla.org/mozilla-central/rev/98ac75c78a63

(In reply to Andrew McCreight [:mccr8] from comment #17)

Not that it really matters, but I think bug 1551302 is the more specific regressor, because that is where the pref was flipped for this feature.

Not sure it matters, but bug 1551302 is where we turned it on for Desktop, it had been enabled on mobile for a while before that.

Ah, ok. I only looked at the desktop prefs file.

Seems like a pretty safe win to take on ESR. Did you want to nominate it for uplift, smaug?

Comment on attachment 9307516 [details]
Bug 1804409, cycle collect mVisualViewport, r=mccr8

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The patch fixes a rather bad memory leak in a somewhat rarely happening case.
• User impact if declined: Memory leaks take resources and make CC/GC times longer.
• Fix Landed on Version: 109
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Should be low risk, it is just traversing/unlinking a member variable.

Looks like the patch applies cleanly to esr102

Comment on attachment 9307516 [details]
Bug 1804409, cycle collect mVisualViewport, r=mccr8

Approved for 102.7esr.

https://hg.mozilla.org/releases/mozilla-esr102/rev/45286505344b