Repository navigation
Description
Before submitting
- I searched existing issues and did not find a duplicate. [Bug]: Leaving a thread detaches its browser preview and can leave automation unusable #6355 has the same trigger (leaving a thread and coming back), but there
preview_statusstill reports the tab as usable and snapshots fail withUnknownVizError. Here the tab's page is destroyed andpreview_statusreports it unavailable. The two may be related. - I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- In a desktop thread, have the agent open a tab with
preview_openforhttps://example.com(tab A), then another withpreview_open,reuseExistingTab: false, forhttps://example.org(tab B). - Have the agent navigate tab A to
https://example.net, so tab A is now the most recently updated tab. - Switch to another thread, come back, and open the browser panel.
- Look at tab A, and have the agent call
preview_statusandpreview_navigateon it.
Expected behavior
Both tabs keep their pages, and the agent can keep using tab A.
Actual behavior
Tab A shows a blank white page. preview_status returns available: false and url: null, and preview_navigate or preview_snapshot on it waits the full 15 seconds and fails with PreviewAutomationTimeoutError. Tab B still works.
preview.list returns tabs sorted by updatedAt, and reconcilePreviewServerSessions rebuilds the session map in that order. ElectronBrowserHost renders one keyed <webview> per tab in the same order, so when the order changes React moves a <webview> element. Electron destroys a webview's guest when its element leaves the DOM, and no new guest attaches when it is inserted again. The element then shows only its white background, while the desktop still has the tab registered to the destroyed WebContents.
A standalone Electron 44.4.2 script shows the same result: moving a <webview> with insertBefore fires destroyed for its WebContents, did-attach does not fire again, and executeJavaScript fails with Invalid guestInstanceId.
Impact
Major degradation or frequent failure
Version or commit
A build of main at 5d707bb. The affected code is unchanged on main at 2679d27.
Environment
Windows 11 x64, T3 Code desktop app (Electron 44.4.2), Claude Code provider. The move behavior comes from Electron's <webview> element, so other platforms are likely affected too. I tested only Windows.
Workaround
Close the blank tab and open a new one.
Activity
kvnloo commentedon Sep 27, 2026
This looks like a useful place to make DOM identity an explicit invariant: changing tab metadata or ordering must never detach/reinsert an existing
<webview>.Could the host render webviews in a stable creation order and make the visible tab order a separate projection? Then
updatedAtcan reorder the tab strip without React ever reordering the underlying<webview>nodes.A regression test could make this very crisp:
That seems safer than trying to repair a guest after Electron has already destroyed it.
mkiera commentedon Sep 27, 2026
Thanks, that's the approach #13799 takes.
ElectronBrowserHostnow renders the webviews sorted by their runtime tab ID, which never changes for a tab, and the tab strip keeps its ownupdatedAtorder. Opening or closing a tab only inserts or removes a node, so an existing<webview>is never moved.The unit test there covers the DOM side: it reorders two tabs by
updatedAtand asserts the rendered webview order is unchanged. Guest survival needs a real Electron, so I checked that with a standalone Electron 44 script: moving a<webview>element destroyed its guest and left a blank box, and with the fixed order the guests stayed alive across reorders.fix(web): browser tabs no longer go white when the tab list reorders