brain-of-reese/.agents/reports/73_hidden_tab_stream/task01_findings.md

Phase 73 / Task 01 — Repro + root-cause findings

Bug (TODO.md L3): "Clicking on another tab while an answer is generating stops that answer from being generated. Responses should continue to generate unless you outright close the tab."

Environment (the "test browser"): real (headful) Chromium 151.0.0.0 (Playwright chromium-1234 build, X11/XWayland on the owner's KDE Plasma Wayland desktop, display :0), launched with ONLY --disable-popup-blocking added (needed for the scripted second tab) — no --disable-*-background* flags, so real hidden-tab behavior is under test. The app ran against the deterministic mock LLM (tests/e2e/mock_llm.py) behind a re-pacing proxy (0.2 s per 12-char SSE frame → a ~90 s stream, a guaranteed mid-stream hidden window), on a scratch Postgres DB (bor_repro73) so no owner data was touched.

Method: two REAL tabs in ONE window (second tab opened via window.open, tab switched via CDP Target.activateTarget / Page.bringToFront — verified real by the document.visibilityState transitions). In-page instrumentation (temporary, removed — no repo changes): pagehide/pageshow/visibilitychange/freeze/resume/ beforeunload/window focus/blur events with timestamps; a 400 ms recorder (visibility, hasFocus, live-bubble text length = frame arrivals, status/banner/button text); CDP Network.* lifecycle of POST /api/chat; performance.getEntriesByType('resource'); localStorage bor.chat.v1; server (uvicorn) log.

Scenario A — mid-stream real tab switch, 65 s hidden (main repro)

task01_A_evidence.json, screenshots task01_A_0…5_*.png, server log server_A.log.

1. Long answer started; at ~7 s (bubble ≈ 460 chars, streaming) the driver switched to the other tab. Tab A went hidden — exactly ONE visibilitychange {state:"hidden"} event, at the switch.
2. While hidden (65 s) the answer kept generating at full wire rate: the live bubble grew linearly 456 → 4141 chars (≈ 58 chars/s = the stream's 12 chars / 0.2 s frame pace) — SSE frames kept arriving the entire time; no stall, no drop, no error copy, no banner. (The 400 ms recorder cadence never degraded — no background timer throttling was observed in this XWayland/KWin environment; noted as an environment property, not an app defect.)
3. Returned to the tab at ~72 s: visibilitychange {state:"visible"}; the turn settled ~18 s later — button back to "Send", no banner.
4. bor.chat.v1: exactly ONE brain turn (the full 5 379-char answer, ending LONG-ANSWER-END) for the one question.
5. pagehide did NOT fire on the tab switch (nor freeze/resume/ beforeunload/pageshow). In real-mode Chromium 151, a merely-hidden tab fires only visibilitychange.
6. Network: POST /api/chat → requestWillBeSent → responseReceived (200) → loadingFinished. No loadingFailed (verified on a clean re-probe: the earlier duplicate/failed entries were a bug in the repro's own CDP event router, not the browser).
7. Server: the turn's settle line shows total_ms=90143/90145 — the server streamed the FULL 90 s to the hidden tab; there is NO chat: turn cancelled line for this turn (the phase-48 line that would prove a real consumer departure).

⇒ In the test browser, a tab switch does NOT stop the answer (C3 and C4 ruled out; C1's trigger did not occur; the guard was already cleared by the first frame, so C2 was not on the path).

Scenario C — C1 double-record path (synthetic pagehide mid-stream)

task01_C_evidence.json, screenshots task01_C_1…3_*.png.

Chromium does not fire pagehide on a tab switch, but browsers that DO (e.g. Safari, which bfcaches/freeze-then-pagehides hidden tabs) would run the app's pagehide handler (frontend/assets/app.js ~L2162) mid-turn. Dispatching a synthetic PageTransitionEvent('pagehide', {persisted:true}) at ~7 s into the stream (bubble ≈ 327 chars) — the EXACT code path a real pagehide executes — then letting the turn complete:

• bor.chat.v1 ended with TWO brain turns for ONE question: the 336-char partial (the pagehide persist) AND the full 5 379-char answer (the done persist).
• After a reload, the restore renders BOTH: user → brain (327) → brain (5 228) — the duplicated / "truncated-looking" conversation the bug report describes.

⇒ C1's corruption branch is real and deterministic whenever the browser fires pagehide on a merely-hidden tab; it never double-persists in Chromium because Chromium never fires that event for a tab switch. This is the branch task 02 hardens unconditionally.

Scenario B — C2 probe: the 120 s guard in a hidden pre-token window

task01_B_evidence.json, screenshots task01_B_1…3_*.png.

The proxy was re-run holding the FIRST frame for 130 s (pre-token silence > TURN_TIMEOUT_MS). The tab was switched away at ~7 s and stayed hidden past the guard's deadline:

• Probes every 10 s while hidden: no banner through t≈117 s; at t≈127 s the button had returned to "Send" and the banner read "That's taking a long time — the answer may be stuck." — the guard fired at its 120 s deadline during the hidden window and errored the turn.
• The first frame would have arrived at t≈130 s — too late: the guard had already aborted the fetch. On return the error banner is still up; the user perceives "switching tabs killed the answer", but the trigger is the pre-token silence, not the switch.
• bor.chat.v1 holds only the user message (pre-token abort persists nothing brain-side — phase-20 convention).
• Server: chat: turn cancelled … total_ms=119999 — the cancellation is the CLIENT's guard abort (client-initiated), not a browser/proxy drop of the hidden tab.

⇒ C2 is confirmed as a real, conditional stop path: any turn whose first frame takes > 120 s errors out if the tab is hidden at the 120 s mark (the guard is a plain setTimeout with no visibility awareness; where a browser DOES throttle background timers, its fire time drifts relative to token arrival, as the C2 branch describes).

Decision-tree verdict

• C1 — pagehide on tab switch: did NOT fire in the test browser (Chromium 151 real mode fires only visibilitychange for a hidden tab). Its double-record corruption path was nonetheless demonstrated deterministically (synthetic pagehide) — latent in browsers that do fire pagehide on hide (e.g. Safari); the trigger is browser-dependent, so task 02's fix applies unconditionally.
• C2 — 120 s guard while hidden: CONFIRMED to fire (scenario B) in the pre-token-only window, erroring the turn with the "stuck" copy.
• C3 — real connection cancel: ruled out (no turn cancelled for the hidden-window turn; loadingFinished, no loadingFailed; full 90 s server-side stream completed).
• C4 — none of the above: in the test browser a merely-hidden tab did NOT stop the answer — it kept generating at full rate and completed on return. The owner's symptom did not reproduce on Chromium 151 desktop; the reproducible stop paths are C2 (slow pre-token + hidden) and C1's corruption (browsers that fire pagehide on hide, e.g. Safari — where a hidden tab is also the likelier place for the stream to actually pause).

One-line root cause (for the phase-73 commit message body): none of C1–C3 — in Chromium 151 (real mode) a merely-hidden tab neither stops the stream (frames arrive at full rate; turn completes) nor fires pagehide on tab switch; C1's double-record path was proven latent via a synthetic pagehide (trigger is browser-dependent, e.g. Safari) and C2 (the 120s pre-token guard) was confirmed to fire while hidden.

Cleanup

• No permanent code changes: git status shows only this (untracked) evidence directory; all instrumentation lived in throwaway scripts under /tmp/repro73/ and in the browser profiles.
• Scratch DB bor_repro73 dropped; repro stack (mock 8901 / proxy 8900 / app 8123) terminated.