Skip to content

[Bug]: A browser tab goes blank white after the tab list reloads in a new order #13798

Open

Description

@mkiera

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_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

  1. 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).
  2. Have the agent navigate tab A to https://example.net, so tab A is now the most recently updated tab.
  3. Switch to another thread, come back, and open the browser panel.
  4. 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.

Workaround

Close the blank tab and open a new one.

Activity

  1. kvnloo commented on Sep 27, 2026

    @kvnloo
    Contributor

    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:

    1. create A then B
    2. record both guest identities
    3. update A so display order becomes A/B instead of B/A
    4. assert the DOM nodes never moved and both guest identities survived
    5. assert only the tab-strip projection changed

    That seems safer than trying to repair a guest after Electron has already destroyed it.

  2. mkiera commented on Sep 27, 2026

    @mkiera
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions