Repository navigation
Description
Every interactive instrument's iframe stays in memory after it is removed, until the host page is reloaded. bootstrap.js runs inside the iframe and registers a MutationObserver on the parent's <html> element to mirror the theme, and nothing ever calls disconnect(). Per the DOM spec a node holds a strong reference to the observers registered on it. So the parent's <html>, which lives for the whole SPA session, keeps the iframe's observer alive. The observer keeps its callback alive, and the callback is a closure in the iframe's realm (it reads the iframe's document), so the iframe's whole global stays reachable. That global holds every module the task loaded (jsPsych, React, the instrument, its data URL assets) and, through frameElement, the iframe element with the full bundle in data-bundle. In a clinic session that administers several interactive tasks, or a series with interactive items, each finished task's memory accumulates. On the tablets used for remote and in-person sessions this grows until the tab is reloaded or killed.
Where
packages/runtime-internal/src/interactive/bootstrap.js:18-35:
// Synchronize the iframe theme with the parent document
const observer = new MutationObserver((mutations) => {
mutations.forEach((mutation) => {
if (mutation.attributeName === THEME_ATTRIBUTE) {
// ...
document.documentElement.setAttribute(THEME_ATTRIBUTE, updatedTheme);
// ...
});
observer.observe(parent.document.documentElement, {
attributes: true
});Reproduce
I confirmed this in Chromium (Playwright's bundled build) with a parent page that mounts and removes five same-origin iframes. Each iframe runs the observer code above verbatim and stores a 2M-element array on its global, and the parent keeps a WeakRef to that array. After the iframes were removed I forced GC with HeapProfiler.collectGarbage:
- without the observer: 0 of 5 iframe globals alive, heap 0.6 MB
- with the observer as written: 5 of 5 iframe globals alive, heap 42.3 MB
- with the observer plus
addEventListener('pagehide', () => observer.disconnect()): 0 of 5 alive
In the app:
- In
apps/web, start a session and complete an interactive instrument (for example the Breakout Task). Then complete another one, or a series with two interactive items. - In DevTools > Memory, take a heap snapshot after each one and filter for
WindoworDetached.
Actual: each completed task leaves a detached iframe Window behind, retained through MutationObserver from the parent's HTMLHtmlElement, and heap usage grows with every task.
Expected: once its iframe is removed, nothing keeps an interactive instrument's realm alive.
Tests
packages/runtime-internal/src/interactive/__tests__/bootstrap.test.ts: it('should stop observing the parent theme on pagehide, so a removed iframe is not kept alive by the parent document'). Bootstrap against the existing fake parent document, dispatch pagehide on window, change the parent's data-mode, and assert that the iframe's data-mode no longer follows it.
e2e, in testing/src/specs/instrument-completion.spec.ts: after completing an interactive instrument, assert through CDP (HeapProfiler.collectGarbage, then Runtime.queryObjects on Window or a WeakRef probe) that the removed iframe's window has been collected.
Suggested fix
In bootstrap.js, add addEventListener('pagehide', () => observer.disconnect(), { once: true }). pagehide fires in the iframe when its element is removed. Also pass attributeFilter: [THEME_ATTRIBUTE] to observe, so the callback stops running on every other attribute change on the parent's <html>.
Activity
joshunrau commentedon Oct 26, 2026
Still reproduces on
main(d86740e).bootstrap.js:18-35has not changed since this was filed, and no open PR touchesruntime-internal/src/interactive/. TheframeElementobserver inSynchronizedTranslator(packages/runtime-core/src/i18n.ts:111-120, called from:155) is not a second leak. It is registered on the<iframe>element, which becomes garbage together with the frame. In a scratch run, a task that also observedframeElementwas collected once thepagehidefix was in.Changes to the suggested fix
persistedand drop{ once: true }. When the host page goes into the back/forward cache, the task document also getspagehide, withpersisted: true(spec). Disconnecting then means the task stops following the theme after a bfcache restore. Withonce, that firstpagehidewould also use up the listener before the real removal. A removed iframe getspersisted: false(checked in Chromium 153 and Firefox 155).attributeFilter, delete theattributeNamecheck at:21. It can no longer be false, and the coverage gate counts that branch. What is left duplicates:11-16, so make it one function.pagehide. All three engines fire it anyway, and Browsers synchronously firepagehide&unload, while the standard doesn't whatwg/html#10194 (open) records Chrome's interest in suppressing it. The e2e test below is what would catch that. A fix that does not depend on it:InteractiveContentpushes itsuseTheme()value (InteractiveContent.tsx:30) intoiFrameRef.current.contentDocumentfrom an effect, andbootstrap.jsdrops the observer. That touchespackages/react-coreas well. I would land thepagehidefix now and keep this as the fallback if the test ever fails.Tests
Unit tests go in
bootstrap.test.ts. One test dispatches a plainpagehide, changes the parent'sdata-mode, waits on a second parent observer as:133-141does, and checks that the iframe kept its theme. A second test dispatchesObject.assign(new Event('pagehide'), { persisted: true })and checks that the sync continues. The property is set by hand because happy-dom aliasesPageTransitionEventtoEvent. Playwright launches Chromium with--disable-back-forward-cache, so only these tests can cover that branch.:133-141keeps passing withattributeFilter, since happy-dom 20.11.15 honours it, and becomes the test for the filter.The e2e test does not fit
instrument-completion.spec.ts. The only built-in interactive instrument, Breakout, callsdoneonly when the game ends (packages/instrument-library/src/interactive/DNP_BREAKOUT_TASK/index.ts:112,:189). Put it inplayground.spec.tsbeside the interactive share-link test at:188-213. When a task finishes in the preview, the summary replaces the task iframe and the preview document stays, which is the same setup asapps/web.render(done)adds a button that callsdone({}). Click Begin.Frames withpage.frame({ name: 'interactive-instrument' })andpage.frame({ url: /preview\.html/ }). The page model'spreviewFrameis aLocator, so add a helper toPlaygroundPage. RuntaskFrame.evaluate(() => { globalThis.probe = {}; }), then storenew WeakRef(iframe.contentWindow.probe)on the preview's global.previewFrame.evaluatethroughiframe.contentDocument, then wait for the task iframe to disappear.context.newCDPSession(previewFrame)(the preview runs out of process). Then runexpect.polloverHeapProfiler.collectGarbagefollowed byderef() === undefined. Do not tag it@smoke, because thefirefoxproject has no CDP.I checked this setup in a scratch harness with a cross-site preview and a delayed removal. The current bootstrap kept the probe alive and the fixed one did not.
Traps:
frameLocator. When the instrument also observedframeElement, it kept the realm alive even with the fix.Runtime.queryObjectscannot replace the probe. It needs an object id for the task realm'sWindow.prototype, and after the frame is removed that id fails withCannot find context with specified id.Triage note written with Claude Code. Code references point at
main@d86740e.