[Bug]: off-window Electron preview guests stall snapshots and block later captures #24514

Area

apps/desktop — collaborative browser automation

Steps to reproduce

1. Run T3 Code Nightly on macOS.
2. Open a fresh, agent-owned preview tab on a simple page:
   preview_open({url: "https://example.com", open: false, reuseExistingTab: false}).
3. Keep its preview hidden, or switch to another thread so the guest is hosted outside the app window.
4. Request preview_snapshot({tabId, includeImage: false}).
5. Repeat the snapshot on the same tab. Compare with preview_evaluate reading document.title or document.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.