Repository navigation
[Bug]: off-window Electron preview guests stall snapshots and block later captures #24514
Description
Area
apps/desktop — collaborative browser automation
Steps to reproduce
- Run T3 Code Nightly on macOS.
- Open a fresh, agent-owned preview tab on a simple page:
preview_open({url: "https://example.com", open: false, reuseExistingTab: false}). - Keep its preview hidden, or switch to another thread so the guest is hosted outside the app window.
- Request
preview_snapshot({tabId, includeImage: false}). - Repeat the snapshot on the same tab. Compare with
preview_evaluatereadingdocument.titleordocument.body.innerText.
Expected behavior
Snapshots of background preview tabs should return the accessibility tree and requested image without requiring the user to reveal the tab or switch threads.
Actual behavior
The snapshot consistently times out, even on example.com and with includeImage: false:
Preview automation snapshot timed out after 15000ms.
JavaScript evaluation still returns immediately. New tabs and an incognito profile reproduce the failure, so it does not depend on the target application or saved browser state. Impact: major degradation / frequent failure of agent browser verification.
Environment
- T3 Code:
0.1.3-nightly.20261024.3604 - macOS 27.0.1, Apple Silicon
- Electron 44.9.3 / Chromium 152.0.7977.167
- Source investigation and regression tests:
main@d53873b6a479 - Codex harness; the failure also reproduces outside the provider in an isolated Electron fixture.
Deterministic isolation and cause
An isolated fixture using the same Electron version, T3's CdpRelay, and the actual ServerBrowserPage.snapshot reproduces the stall when the guest webview is positioned at left: -100000px; top: -100000px.
The metrics, page evaluation, and accessibility-tree requests answer. Page.captureScreenshot does not. Disabling background throttling does not restore composition for a guest fully outside the window. includeImage: false does not avoid this path because snapshot capture still obtains an image internally.
The desktop host serializes screenshot requests to avoid overlapping native captures. An unanswered screenshot therefore also holds up subsequent screenshots on that guest.
Moving the guest into the window behind the app for the duration of capture, waiting for the renderer to commit that position, and releasing it afterwards makes the same full snapshot complete. The regression fixture returned three consecutive 1280×960 snapshots, then three more in a fresh Electron process. The guest remains inactive between captures.
Related reports
Related symptoms: #23936, #22594, #17483, #23139. This report adds a deterministic off-window compositor reproduction and a focused fix for this capture path; it does not establish that every timeout in those reports has the same cause.
Fix
Implemented in #24515, including the capture lifecycle fix and regression tests.
Activity
RiccardoBelli commentedon Oct 26, 2026
Same here on Linux (Arch, Hyprland/Wayland), t3code-bin 0.1.2 installed with the server still on 0.1.0, Electron 44.4.5, Claude Code harness.
An agent tab opened with
open: falsedraws no frames. ArequestAnimationFramecallback never runs within a second, even ifdocument.visibilityStatesaysvisible.preview_snapshoton that tab times out after 15 s. On the tab shown in the panel it works. If the agent first callspreview_openwith thetabIdandopen: true, frames start and the snapshot works.Two more things I saw, maybe useful for #24515:
preview_openwithopen: trueon that tab hung untilPreview automation open timed out after 660000ms, andpreview_evaluatetimed out after 15 s. Only closing the tab fixed it. So the agent can't even reveal the tab to recover.HOST_RESPONSE_GRACE_MS) the broker disconnects the whole host connection. The next call on any tab fails withNo preview automation host is available for snapshot ...until it reconnects about 1 s later. We first thought parallel snapshot calls caused this, but the second call just started in that gap.juliusmarminge commentedon Oct 27, 2026
This is fixed on main by fd71ddc223 (#25184). That commit landed on 2026-10-25, after
0.1.3-nightly.20261024.3604and afterd53873b6a479.What changed: while a
Page.captureScreenshotis pending on a guest, the desktop host now publishes apaintingstate, and the client keeps that guest inside the window behind the app (left: 0; top: 0; z-index: -1) until the capture settles. It then goes back off-window. The screenshot queue also moves on when a turn ends, the relay is released, or the page navigates, so a capture that never answers no longer blocks later ones on that tab.What I ran on main
4cb29a56f6(Linux, Xvfb):<webview>guest at-100000px, andsetBackgroundThrottling(false)reproduces your isolation exactly.Runtime.evaluateandAccessibility.getFullAXTreeanswer, andPage.captureScreenshottimes out. So the stall isn't macOS-only.apps/desktopManager.test.tsandDesktopBrowserHost.test.tspass (88 tests). They include "paints a hidden guest only while the screenshot it is taking is pending" and "stops painting for a screenshot Chromium never answers".Closing as fixed. If
preview_snapshoton a hidden tab still times out on a nightly built after 2026-10-25, reopen with that version.