fix: phone background/return says nothing (RO toast, quiet context loss) - #527

Switching away from the browser on a phone and coming back should say nothing. Two pieces of noise showed up after a minimise/restore on an Android foldable (1.57.0, empty editor scene).

Not for its own release. The next integration merges this and its battery covers it.

What changes

• Error toast. "Something went wrong" now skips the messages error reports already ignore (errorReportCore IGNORE: ResizeObserver loop, Script error., an interrupted play(), aborts). It uses the same list, through diagnostics.toastsUncaught(). The line still goes into the diagnostics ring, so Copy diagnostics keeps it.
• Lost 3D view. A new leaf, src/lib/contextLoss.js, holds a pure grace rule plus startContextLossGate. A new store, sceneStore.contextLossShown, is the "loud" half of a context loss.
  • A loss turns loud only after the page has been visible for 3 s with the context still gone. The clock starts at whichever comes later: the loss, or the page becoming visible. Hiding the page stops the clock.
  • ContextLostOverlay and the webgl error report now read contextLossShown.
  • contextLost itself is unchanged and still raw, so the shader guard reacts at once.
  • preventDefault() and the material recompile on restore are unchanged.
• Signaling drop. No change (41 G21: the Connect dot carries it). The new suite checks that it raises no toast and that the dot comes back on the same peer id.

Proof

• Unit test tests/unit/backgroundQuiet.test.js: both rules use one shared list; the grace timing covers hidden/visible, restore inside or outside the grace, hide stopping the clock, and the gate driving the store. 16 tests, all green.
• New e2e suite background-quiet (phone emulation, real WEBGL_lose_context, report URL routed to a mock): ALL PASS.
  • Page hidden → context lost + signaling socket dropped → page shown → context restored inside 3 s: no overlay at any moment, no toast, no report. The Connect dot returns on the same id.
  • A loss on a visible page: no overlay at 1.5 s; the overlay shows at 4 s and one webgl report goes out; restoring takes the overlay down.
  • A real ResizeObserver loop reaches the ring with no toast. Control: a real error still toasts.
• Counterfactual on v1.57.0 is red on 1a/1c/1e (overlay and webgl report while hidden), 2a and 3b (the RO toast).
• dispose and error-reports now wait out the grace before asserting the overlay or report. Both green.
• node scripts/check-ratchet.cjs: 278/39, equal to the baseline. npm run build: rc 0.

Where the ResizeObserver loop came from: not reproduced

An init script wrapped ResizeObserver to record each observer's creation site and every loop error. It was checked with a positive control (5 loops recorded). Then the reported size (691×634 @3.25 with touch) was replayed on a GPU slot and on a software-render slot, with 28–98 observers live. 0 app loops in all of these:

• boot
• rotate
• fold/unfold (390×896 ↔ 770×850)
• keyboard (height 330)
• minimise/restore
• a signaling drop, unfolded and folded
• a 360–800 px resize sweep
• URL-bar height jitter
• Statistics, Objects, Explorer, the Connect drawer and Settings, each open through all of the above

Notes:

• At 691 px the app draws the desktop layout, not the phone shell.
• Ruled out by reading the code: the phone Connect chip's fit() (its wrapper is position: fixed with left/right set, so the chip's size cannot feed back into it). PhoneDockHost, TouchTools and fullName already defer to rAF.
• ro-loop-guard already covers the unfolded/folded feature phases.

The toast is gone either way. If the loop shows up again, the line in Copy diagnostics carries its timestamp.

🤖 Generated with Claude Code