[Bug]: Windows preview snapshots and remote viewing stall while T3 is completely covered#23139

Retest: still reproduces on Windows Nightly 0.1.2-nightly.20261021.3499 with Android 2.0.0 (build 362).

This Windows build contains the main revision requested in triage.

Used a fresh agent-owned Default-profile tab on https://example.com. T3 was fully covered by another maximized application (Codex Desktop), not minimized.

Covered versus foreground

While covered, the page reported visibilityState: "visible", hasFocus: true, and a 1280×800 viewport. A requestAnimationFrame callback fired after approximately 1 ms.

Android viewing: stuck on “Connecting to browser” while T3 was covered. It recovered immediately when T3 was brought to the foreground, before the foreground snapshot was requested.

One covered snapshot attempt and one foreground retry were performed. No settings changes, Chromium flags, restarts or installs occurred during the comparison.

Sanitized trace excerpt

October 21, 2026; local times, UTC−05:00. Table durations above are outer MCP tool-call spans; the excerpt below shows inner broker spans.

T3 was brought to the foreground around 20:39:56. The respond at 20:39:57 had no agent request in flight, but we cannot correlate it to the earlier failed snapshot.

The desktop trace contains tab/webview initialization spans, but no preview/capture spans during either snapshot attempt.

Conclusion: the covered/foreground dependency is reproducible on this Windows build, and Android viewing recovers with foregrounding. These observations do not establish the underlying cause. The working rAF callback shows the page event loop was responsive; it does not establish that capture or streaming frames were available.

This also reproduces on a Linux host. The host user does not have to cover the window: the host desktop app draws every server-runtime tab of its primary environment (ElectronBrowserHost.tsx:33-40, rendersServerTabNatively in previewRuntime.ts:44-55). If nobody has that thread open on the host's own screen, the tab is never on screen there. That is always the case when the user works from another machine.

The setup is the same as Comment A: a Linux desktop host on 3541 with a Windows desktop client.

1. preview_open({url: "http://127.0.0.1:8741/page.html", open: false, reuseExistingTab: false}).
2. Run preview_evaluate("({w: innerWidth, h: innerHeight, dpr: devicePixelRatio})"). It returns {w: 1280, h: 800, dpr: 1}, with a T3CodeNightly/...Electron user agent.
3. Run preview_evaluate("new Promise(r => { const t = setTimeout(() => r('no rAF in 3s'), 3000); requestAnimationFrame(() => { clearTimeout(t); r('rAF ok'); }); })"). It returns "no rAF in 3s".
4. preview_snapshot fails with Preview automation snapshot timed out after 15000ms. Running preview_navigate, preview_scroll and preview_evaluate on the same tab right afterwards works.
5. Remote viewers of the tab get a stale or missing frame, because the screencast has nothing to send.

The cause: when a tab is not on the host's screen, the inactive wrapper parks the guest at HIDDEN_BROWSER_WEBVIEW_OFFSET with visibility: hidden (hostedBrowserWebviewStyle.ts:66-74). keepPaintableWhenInactive is set only on macOS (HostedBrowserWebview.tsx:301). The only acquireActivity caller is recording (browserRecording.ts:537), so a remote viewer or an agent snapshot never keeps the guest painting. Event-loop stalls do not explain these timeouts: the host's event-loop-stalls.ndjson has no entry between 14:51Z and 15:19Z, when the timeouts happened, and today's largest stall is 2.8 s.

#22743, which moves agent tabs into their own never-shown BrowserWindow, would cover agent-opened tabs. A tab the user opened and views remotely needs the same treatment, or an activity lease while any remote viewer is attached.

See also #23936.

Confirmed on a Linux host with two minimize-and-restore cycles on 0.1.3-nightly.20261023.3579. This adds a newer-build Linux reproduction to the existing Linux report above.

Host: Ubuntu 24.04.5 LTS, x86_64, GNOME 46, Wayland. The T3 desktop app runs the local server. Both desktop version and running serverVersion were verified as 0.1.3-nightly.20261023.3579, using the installed desktop package and /.well-known/t3/environment. The remote client is the Windows T3 desktop app.

Each attempt used a fresh tab opened with:

On each returned tabId, we ran status, DOM evaluation, and one snapshot. On the host, the target thread was selected and its Browser panel open before the controlled comparison.

DOM evaluation returned title: "Example Domain", readyState: "complete", and visibility: "visible" in every row. Opening the fresh tab did not restore the minimized host window.

Both failed snapshot modes returned exactly:

Sanitized server trace excerpts, October 23, 2026, UTC:

Each retained the inner cause:

The installed ServerBrowserPage uses a 10,000 ms snapshot deadline, while the outer error reports 15,000 ms. The installed MCP handler removes includeImage before invoking snapshot capture, so includeImage: false does not bypass the screenshot operation.

Limits: earlier exploratory attempts had not verified the host's selected thread and Browser panel, so they are excluded from the comparison above. Screen locking is disabled by host policy, so no valid locked-state test was possible. The user initially saw "Connecting" in both Windows inline and floating viewers, but viewer display after recovery and Windows mouse input were not verified. macOS was not tested. No capture settings, application files, or Chromium flags were changed, and T3 was not restarted. All test tabs were closed.

This confirms a host-visibility dependency on Linux. It does not prove the exact Electron mechanism or that the full remote-viewing/input problem is fixed.

Investigated and drafted with GPT-6.1 Sol through the Codex harness in T3 Code.