[Bug]: A slow typed navigation blocks all input in an environment-hosted browser tab for 15 seconds #16641

Activity

1. juliusmarminge commented on Oct 7, 2026

   

   juliusmarminge

   on Oct 7, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Confirmed on current main (517188b).

   Root cause. All human input for a tab goes through one serialized queue, and viewer navigations wait for the commit inside that queue:

   • apps/server/src/preview/SessionControl.ts:37-44 (enqueue) chains every action on tail, so each one starts only after the previous one settles (plus any pending work registered through track, :47-53). human() (:100-102) → action() (:65-74) → enqueue.
   • apps/server/src/preview/ServerBrowser.ts:2112-2114 runs every viewer message inside tab.control.human(viewer.id, () => dispatchViewerInput(...)). The surrounding catch (:2116-2119) swallows the failure.
   • In dispatchViewerInput (ServerBrowser.ts:1790), these all await VIEWER_NAVIGATION_OPTIONS = { waitUntil: "commit", timeout: 15_000 } (:119-120):
     • navigate awaits tab.page.goto(url, VIEWER_NAVIGATION_OPTIONS) (:1884-1889)
     • history awaits goBack/goForward (:1890-1894)
     • a soft reload awaits page.reload (:1895-1902)

   A typed URL whose host never answers holds the queue for the full 15s. Clicks, scrolls, keys, Back and a corrected URL wait behind it. When goto times out, the TimeoutError is dropped and Chromium keeps the request alive, so the tab keeps showing Loading.

   Suggested fix direction. A new human navigation should replace a slow one instead of waiting behind it:

   • Don't await the commit inside the human queue. Start the navigation and return, as the agent path does with readiness: "none" (ServerBrowser.ts:1185). Note that track() would still make later actions wait, so the viewer path should not register the navigation as pending. Alternatively, race it against the next viewer input.
   • When a new viewer navigate/history/reload arrives, call Page.stopLoading (or start a new goto, which cancels the old one in Chromium) first, so the old load is abandoned as it would be in Chrome.
   • Optionally surface a navigation timeout or net error to the viewer instead of swallowing it.

   Related. #16567 is the same SessionControl queue with no per-action deadline, triggered there by an agent preview_snapshot that never settles. A per-action deadline in SessionControl would help both issues, but this one also needs the human-navigation change above, because a 15s hold is "within deadline". I didn't find an open PR that touches SessionControl or the viewer navigation path.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 7, 2026