Description
In packages/app/src/context/server-sdk.tsx, pagehide always calls stop() on the event stream (lines ~325-328), but pageshow only calls start() again if event.persisted === true (resumeStreamAfterPageShow, lines 162-165).
Since the event stream itself is an open streaming fetch() connection, it is a known bfcache blocker in most browsers — meaning the page is often not bfcache-eligible, so persisted comes back false on pageshow, and start() is never called.
Result: After backgrounding/returning to the tab (switching apps, locking screen, etc.), the live event stream stays dead and the UI stops reflecting session updates until a full manual page refresh remounts the app.
Confirmed as web-UI-specific: OpenChamber (a third-party client using the same server API/event stream) does not exhibit this issue — server side is fine.
Relevant code:
// lines 162-165
export function resumeStreamAfterPageShow(event: PageTransitionEvent, start: () => unknown) {
if (!event.persisted) return
start()
}
// lines 325-328 (onMount)
makeEventListener(window, "pagehide", stop)
makeEventListener(window, "pageshow", (event) => resumeStreamAfterPageShow(event, start))
### Plugins
_No response_
### OpenCode version
_No response_
### Steps to reproduce
_No response_
### Screenshot and/or share link
_No response_
### Operating System
_No response_
### Terminal
_No response_
Description
In
packages/app/src/context/server-sdk.tsx,pagehidealways callsstop()on the event stream (lines ~325-328), butpageshowonly callsstart()again ifevent.persisted === true(resumeStreamAfterPageShow, lines 162-165).Since the event stream itself is an open streaming
fetch()connection, it is a known bfcache blocker in most browsers — meaning the page is often not bfcache-eligible, sopersistedcomes backfalseonpageshow, andstart()is never called.Result: After backgrounding/returning to the tab (switching apps, locking screen, etc.), the live event stream stays dead and the UI stops reflecting session updates until a full manual page refresh remounts the app.
Confirmed as web-UI-specific: OpenChamber (a third-party client using the same server API/event stream) does not exhibit this issue — server side is fine.
Relevant code: