You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: A browser tab goes blank white after the tab list reloads in a new order #13798
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_status still reports the tab as usable and snapshots fail with UnknownVizError. Here the tab's page is destroyed and preview_status reports 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_open for https://example.com (tab A), then another with preview_open, reuseExistingTab: false, for https://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_status and preview_navigate on 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.
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 updatedAt can reorder the tab strip without React ever reordering the underlying <webview> nodes.
A regression test could make this very crisp:
create A then B
record both guest identities
update A so display order becomes A/B instead of B/A
assert the DOM nodes never moved and both guest identities survived
assert only the tab-strip projection changed
That seems safer than trying to repair a guest after Electron has already destroyed it.
Thanks, that's the approach #13799 takes. ElectronBrowserHost now renders the webviews sorted by their runtime tab ID, which never changes for a tab, and the tab strip keeps its own updatedAt order. 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 updatedAt and 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.
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