Context
Found while closing the pane leg of #16425. With the DockFlip starvation repair in place (entry discriminator + timer dam, branch agent/16425-dockflip-starvation-dam, a4a013aa1b), a dense tour in a genuinely hidden browser pane now RUNS — scene captions advance, the cross-zone showcase completes its two dwells, pips paint — and SETTLES with a receipt instead of wedging in the preamble. The remaining fail-closed stop moved one leg further down the cue chain:
Tour stopped — overflow: overflow returned no observable receipt
Measured live at 2026-08-03T10:52Z: document.hidden: true, real 1280×720 bounds, 33 rows, 31 sparkline canvases, all sparklines offscreenRegistered: true pre-tour. The canvas-update stop from #16425 is gone; overflow is the next (and per the cue receipts, likely last) starved cue leg.
The Problem
The starvation family drains leg by leg, and each leg has a different owning seam:
- Grid geometry acquisition — repaired at the ResizeObserver addon (#16402, merged
e10992deb3).
- Dock re-projection choreography — repaired at the DockFlip addon (#16425 PR, two layers: hidden entry discriminator + occluded timer dam).
- The overflow cue — THIS ticket.
executeCue('overflow') → Workspace#navigateOverflowMenu(cue.itemId) returns no observable receipt in a genuinely hidden pane, while the same cue settles with a receipt object under the synthetic starvation rig (WorkstationStarvedTourNL, completed 6/6 cues) and headed.
The synthetic rig does NOT reproduce this leg — that is the classification's first datum. The rig lies about document.hidden to JS readers but its timers run unclamped and its compositor is live. A genuinely hidden pane adds two things the rig lacks: (a) visibility-clamped main-thread timers (>=1s/tick, intensive ~1 wake/min after 5min hidden), and (b) real zero-serviced compositor state including stale/zero measurement geometry for floating surfaces.
The Architectural Reality
The overflow surface has multiple starvation-sensitive legs, and the classification must name the one that fails:
Workspace#navigateOverflowMenu drives the floating overflow control + its menu (component identity via getTabChromeIdentity: overflowControlId, overflowPluginId).Workspace#waitForOverflowMenu requires four lifecycle facts (!plugin.measuring, !plugin.projectQueued, control.mounted, control.menuList) inside a bounded 100×timeout(0) app-worker poll.tab.plugin.Overflow#project() measures per-button geometry through main-thread reads and coalesces while a measurement is in flight — a hidden pane can hold measuring/projectQueued in states the visible path never lingers in, and zero-width button rects can produce a degenerate partition (no overflow → no control → no receipt).- The menu itself imports/mounts asynchronously after control construction.
The Fix
Classification-first, in the REAL pane (the rig cannot reproduce it; the pane route is documented on #16402/#16425: preview_start fronts once = bounds, then hidden; NL MCP with explicit sessionId):
- Instrument
navigateOverflowMenu + the Overflow plugin's measurement lifecycle in a hidden pane; capture which of the four readiness facts never becomes true, or which measurement leg returns degenerate geometry.
- Repair at the owning seam so the cue produces its observable receipt without rendering opportunities — measurement legs must ride message-driven reads (layout is live in hidden documents; only paint is dead), and any main-thread timer cadence must respect the visibility clamp (see the sibling timer-throttling ticket).
- Witness: the dense tour completes in a genuinely hidden pane (
Tour complete — 11 deterministic beats and 6 surface cues settled.) — closing the LAST leg of the operator-reported hidden-pane symptom. Extend the synthetic rig with the classified discriminating condition if it can be modeled deterministically.
Acceptance Criteria
Out of Scope
- Grid geometry under starvation — #16402 (closed).
- DockFlip choreography under starvation — #16425 (PR in flight).
- Overflow control z-order — #16424. Card viewport sizing — #16423.
Related
Related: #16425 · #16402 · #16424 · #16412 · #16356
Live latest-open sweep: checked latest 20 open issues at 2026-08-03T10:57Z; no equivalent found (#16424 is overflow z-order, #16412 is tour reset topology — different seams). A2A in-flight claim sweep: latest 30 messages spanning the herd window — no overlapping claim.
Origin Session ID: f01a83b0-dab9-4fa9-a3a1-279f3e2336dd
Retrieval Hint: "overflow cue starvation hidden pane tour no observable receipt"
Context
Found while closing the pane leg of #16425. With the DockFlip starvation repair in place (entry discriminator + timer dam, branch
agent/16425-dockflip-starvation-dam,a4a013aa1b), a dense tour in a genuinely hidden browser pane now RUNS — scene captions advance, the cross-zone showcase completes its two dwells, pips paint — and SETTLES with a receipt instead of wedging in the preamble. The remaining fail-closed stop moved one leg further down the cue chain:Measured live at 2026-08-03T10:52Z:
document.hidden: true, real 1280×720 bounds, 33 rows, 31 sparkline canvases, all sparklinesoffscreenRegistered: truepre-tour. The canvas-update stop from #16425 is gone; overflow is the next (and per the cue receipts, likely last) starved cue leg.The Problem
The starvation family drains leg by leg, and each leg has a different owning seam:
e10992deb3).executeCue('overflow')→Workspace#navigateOverflowMenu(cue.itemId)returns no observable receipt in a genuinely hidden pane, while the same cue settles with a receipt object under the synthetic starvation rig (WorkstationStarvedTourNL, completed 6/6 cues) and headed.The synthetic rig does NOT reproduce this leg — that is the classification's first datum. The rig lies about
document.hiddento JS readers but its timers run unclamped and its compositor is live. A genuinely hidden pane adds two things the rig lacks: (a) visibility-clamped main-thread timers (>=1s/tick, intensive ~1 wake/min after 5min hidden), and (b) real zero-serviced compositor state including stale/zero measurement geometry for floating surfaces.The Architectural Reality
The overflow surface has multiple starvation-sensitive legs, and the classification must name the one that fails:
Workspace#navigateOverflowMenudrives the floating overflow control + its menu (component identity viagetTabChromeIdentity:overflowControlId,overflowPluginId).Workspace#waitForOverflowMenurequires four lifecycle facts (!plugin.measuring,!plugin.projectQueued,control.mounted,control.menuList) inside a bounded 100×timeout(0)app-worker poll.tab.plugin.Overflow#project()measures per-button geometry through main-thread reads and coalesces while a measurement is in flight — a hidden pane can holdmeasuring/projectQueuedin states the visible path never lingers in, and zero-width button rects can produce a degenerate partition (no overflow → no control → no receipt).The Fix
Classification-first, in the REAL pane (the rig cannot reproduce it; the pane route is documented on #16402/#16425:
preview_startfronts once = bounds, then hidden; NL MCP with explicit sessionId):navigateOverflowMenu+ the Overflow plugin's measurement lifecycle in a hidden pane; capture which of the four readiness facts never becomes true, or which measurement leg returns degenerate geometry.Tour complete — 11 deterministic beats and 6 surface cues settled.) — closing the LAST leg of the operator-reported hidden-pane symptom. Extend the synthetic rig with the classified discriminating condition if it can be modeled deterministically.Acceptance Criteria
Out of Scope
Related
Related: #16425 · #16402 · #16424 · #16412 · #16356
Live latest-open sweep: checked latest 20 open issues at 2026-08-03T10:57Z; no equivalent found (#16424 is overflow z-order, #16412 is tour reset topology — different seams). A2A in-flight claim sweep: latest 30 messages spanning the herd window — no overlapping claim.
Origin Session ID: f01a83b0-dab9-4fa9-a3a1-279f3e2336dd
Retrieval Hint: "overflow cue starvation hidden pane tour no observable receipt"