fix: memory leak from detached snap iframes

[ocnc]

Note

Addresses memory leaks in snap execution lifecycle.

• In IframeExecutionService.terminateJob, cast to HTMLIFrameElement, navigate to about:blank, then remove the iframe to ensure the prior document unloads (notably for Firefox)
• In BaseSnapExecutor.onTerminate, remove unhandledrejection and error listeners if registered and clear handler refs to enable garbage collection

^{Written by Cursor Bugbot for commit 4e1b218. This will update automatically on new commits. Configure here.}

This fix should address:

MetaMask/metamask-extension#38847
MetaMask/metamask-extension#34428
MetaMask/metamask-extension#35567

My profiler showed a firefox extension (Metamask) hogging > 10GB of RAM, and the digging lead to finding event listeners aren't cleaned up on termination

[Jeko83]

looks good to me

[FrederikBolding]

Do you have a way to reproduce/prove this? When I tested locally, about:memory did not show any references to Snaps iframes after they were removed.

[ocnc]

Hi, thanks for getting to this:

Reproduction environment:

Firefox 146.0.1
MacOS 26.2

Steps for reproduction:

1. Completely quit firefox & reopen to a fresh window
2. Unlock metamask, close extension window
3. about:memory -> GC
4. Open a tab, navigate to app.aave.com (i think any dapp works). Connect wallet (disconnect if already connected)
5. Wait a minute
6. about:memory -> GC -> Measure & Save a memory report
7. Wait another few minutes
8. about:memory -> GC -> Measure & Save a memory report

Evidence of Memory Leak

Controlled Test (Firefox)

Fresh browser profile, measured with about:memory after forcing GC:

Time	Action	Active	Detached	Leaked
0:00	Fresh unlock	0	0	0 MB
+1 min	Connect to dapp	5	1	~7 MB
+5 min	Waiting around	3	8	~47 MB
+7 min	Final measurement	4	12	~68 MB

Result: 68 MB leaked in 7 minutes of normal usage

What's happening

1. Snaps create iframes at execution.metamask.io
2. When terminated, iframe.remove() is called
3. But event listeners keep references → iframes stay in memory
4. Firefox reports them as top(none)/detached/ (removed from DOM, still in memory)

[Diewi]

Hi, thank you very much for the fix. I'm another affected user and could verify that the change is resolving the memory leak. Just to be seen as an independent verification and that no other hidden issue is causing this (smoke test).

OS: Arch Linux
Firefox: 146.0.1

Test setup:

• Verified the issue is present with locally build "metamask-extension": The memory leak is even present when firefox is started with the extension and idling afterwards.
• Recompiled "metamask-extension" with a locally built "snaps" with the patch applied:
  • Memory leak did not appear after ~15 mins of idling
  • With connection to dApp: No memory leak
  • No memory leak after ~4 hours of general usage.

[FrederikBolding]

Hmm, not sure how I didn't spot the detached windows when testing the first time. It doesn't seem like the changes in this PR fixes the issue though, I still see detached windows after garbage collection has run 🤔