[Bug]: Interactive scene iframe has no keep-alive — reloads on every remount (scene switch, mode toggle, re-parent)

[wyuc]

Summary

Interactive scene iframes reload (re-execute their HTML/scripts) whenever the playback chrome unmounts and remounts. The most visible trigger is toggling Pro mode (edit ↔ playback), but the root cause is structural and not specific to the editor: any path that tears down and rebuilds PlaybackChromeRoot re-mounts the iframe from scratch.

Steps to reproduce

1. Open a classroom whose current scene is an interactive (iframe) scene.
2. Toggle Pro mode on, then off (or trigger any flow that unmounts/remounts the playback chrome).
3. Observe the interactive scene reload: the iframe re-parses its HTML and re-runs its scripts, losing any in-iframe state.

Root cause

Stage switches between EditChromeRoot and PlaybackChromeRoot via AnimatePresence as two mutually exclusive branches keyed by mode. Entering Pro mode unmounts the whole PlaybackChromeRoot subtree; exiting rebuilds it.

Stage (mode swap via AnimatePresence)
  └─ PlaybackChromeRoot      ← unmounted on edit, rebuilt on return
       └─ CanvasArea
            └─ SceneRenderer
                 └─ InteractiveRenderer  ← <iframe srcDoc> mounts fresh

InteractiveRenderer renders <iframe srcDoc={patchedHtml}> directly in the React tree (components/scene-renderers/interactive-renderer.tsx). There is no iframe reuse/persistence (e.g. portaling a single iframe into a stable host node), so a remount means a full reload.

This is pre-existing behavior of the playback chrome. The editor work merely adds a prominent new way to trigger it.

Impact

• Interactive widget state is lost on every Pro mode toggle.
• Visible reload flash; wasted work re-parsing/re-running iframe content.
• Affects any future remount trigger, not just Pro mode.

Candidate fixes (need a direction decision)

1. Persist the iframe: portal one iframe instance into a stable DOM host outside the mode-swap subtree, show/hide instead of unmount.
2. Keep PlaybackChromeRoot mounted across mode swaps (hidden, not unmounted) so its iframe survives.
3. Cache/restore iframe state at the widget messaging layer (widget-iframe store) — partial, only covers state the widget cooperates on.

Option 1 or 2 fixes it generally; both touch the playback chrome architecture, so this should land as its own change rather than riding along with the slide-editor PR.

Notes

Out of scope for the MAIC Editor slide-surface PR (#615) — filing separately so that PR stays focused.

[wyuc]

Refining the root cause and scope after a closer read of feat/maic-editor-v0.

The reload is not specific to the Pro mode toggle. The interactive iframe's document lifetime is bound entirely to React's reconciliation of the scene subtree — InteractiveRenderer renders <iframe srcDoc> inline. Whenever that <iframe> element unmounts, or is merely re-parented in the DOM, the browser drops the document and re-parses/re-executes from scratch. There is no keep-alive anywhere.

Triggers that all reload today:

• Mode toggle: PlaybackChromeRoot unmounts on entering edit, rebuilds on exit.
• Scene switch and back: A(interactive) → other → A remounts InteractiveRenderer; even interactive→interactive reloads via changed srcDoc.
• Any PlaybackChromeRoot remount (re-key, conditional flip).
• DOM re-parent: per spec, re-inserting an iframe reloads it, so "move the iframe between the edit and playback trees" is not viable.
• (dev only) StrictMode double-mount reloads twice, masking the real frequency.

So the mode-toggle case is one instance of a general problem: the iframe is never persisted across any remount.

Revised fix direction — a keep-alive iframe pool:

• Own the interactive iframes outside the reconciled scene subtree (a stable host at the Stage root), keyed by scene (or content hash). Created once, never unmounted on scene/mode changes; only position and visibility update.
• In-tree InteractiveRenderer becomes a placeholder that reports target rect / visibility / active scene (reusing use-tracked-rect); the real iframe is positioned over the canvas box from the host.
• Only a true content change (html hash) rebuilds an entry. Mode toggle, back-and-forth scene switching, and re-renders all hit the cache with zero reload and zero flash.
• Tradeoff: cached iframes are resident DOM/memory, so bound the pool (LRU / current ±1). widget-iframe is already per-scene keyed and can grow into the pool owner rather than adding a parallel mechanism.

This supersedes the three earlier candidates: option 1 (portal one iframe) is the narrow version of this; option 2 (keep PlaybackChromeRoot mounted) fights the deliberate teardown of the playback engine/SSE/TTS; option 3 (widget-cooperative save) is partial and only useful as a complement.