[robrab2000]

When a remote viewer attached to a preview tab, the server captured a still of the page before the attach returned, and the stream route only upgrades the WebSocket once the attach is done. If the tab's renderer had stopped answering CDP, that capture never came back, so the phone sat on "Connecting to browser..." until the tab was closed.

attachViewer now fires the still after startScreencast without awaiting it, so the socket opens while the page is not answering. The mobile preview fails to "The page is not responding. Reconnect to try again." after 30 s with the socket open but no frame. The other half, bounding captureViewport so a hung capture releases the tab's capture lock, is #23515 and is not duplicated here.

Verification:

• New test "a viewer attaches while the page is not answering its still capture" in ServerBrowser.test.ts hangs until the project timeout on main and passes here; vp test run apps/server/src/preview/ServerBrowser.test.ts is green (29 tests).
• vp fmt --check, vp lint on the changed files, and typecheck for apps/server and apps/mobile pass.
• The mobile timeout is untested on a device; no screenshots.

Fixes #24852
Refs #23022 #23515

Claude Fable 5.1 via Claude Code in T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at d222e09

Macroscope's review found this PR approvable — This is a narrowly scoped preview-stream bug fix: the server no longer blocks viewer attachment on an unresponsive still capture, and the mobile client reports a bounded timeout instead of hanging indefinitely. Existing frame delivery is preserved and the affected behavior is covered by a live test.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: e57c093
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: bec9e597-805d-4d9f-b845-746715351aaa

Commits

Reviewing files that changed from the base of the PR and between e57c093 and d222e09.

Files selected for processing: 3

• apps/mobile/src/features/browser/PreviewStreamWebView.tsx
• apps/server/src/preview/ServerBrowser.test.ts
• apps/server/src/preview/ServerBrowser.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Walkthrough

The server no longer waits for the initial fallback still capture before returning viewer setup. The mobile view reports a page-not-responding error if it remains connecting for 30 seconds without a first frame.

Changes: Remote preview first-frame handling

Layer / File(s)	Summary
Asynchronous viewer setup and validation apps/server/src/preview/ServerBrowser.ts, apps/server/src/preview/ServerBrowser.test.ts	Viewer setup now continues while the fallback still capture runs. Tests check viewer outputs before capture resolves and verify frame data after it resolves. The read-only viewer test collects outputs until a frame arrives.
Mobile first-frame timeout apps/mobile/src/features/browser/PreviewStreamWebView.tsx	If the stream has started and remains connecting for 30 seconds, the mobile view fails with “The page is not responding. Reconnect to try again.” The timer is cleared when its effect is cleaned up.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Possibly related issues

• pingdotgg/t3code#22461 — This change also removes the initial still capture from the viewer setup wait.
• pingdotgg/t3code#23015 — The viewer can connect before the mobile view reports that a first frame did not arrive.
• pingdotgg/t3code#24228 — This change addresses the remote preview connection wait, though the issue also mentions snapshot timeouts.

Suggested labels: bugfix, size:XS

Suggested reviewers: juliusmarminge, maria-rcks

Merge Risk: Minimal · up to d222e

The viewer can finish connecting while the initial still capture is pending, and the mobile view offers reconnect if no frame arrives. No merge-blocking issue was established.

Pre-merge checks: 3 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Description check		The description clearly explains the problem, implementation, linked issues, verification results, and known limitations. It does not provide explicit maintainer approval for the scope, and it does no…	Add the maintainer approval comment or explain why this focused bug fix qualifies without prior approval. Upload and embed before/after screenshots, plus a short recording if needed to demonstrate the 30-second timeout and reconnect behavio…

Passed checks: 3 passed

Check name	Status	Explanation
Title check		The title clearly identifies the preview connection failure caused by an unresponsive still capture. It is concise, specific, and uses a conventional commit format.
Linked Issues check		The PR meets the coding requirements for [#24852]. ServerBrowser.attachViewer starts pushStill() without awaiting it after startScreencast, so viewer setup can complete while the initial capture…
Out of Scope Changes check		The changes stay within [#24852]. The mobile timeout implements the required reconnect error. The server test covers the viewer attach behavior. The existing read-only viewer test change waits for an …

Full details: Linked Issues check

Explanation

The PR meets the coding requirements for [#24852]. ServerBrowser.attachViewer starts pushStill() without awaiting it after startScreencast, so viewer setup can complete while the initial capture remains pending. PreviewStreamWebView reports “The page is not responding. Reconnect to try again.” after 30 seconds without a frame. The new server test covers a pending still capture and verifies that viewport and control outputs arrive before the frame.

Full details: Out of Scope Changes check

Explanation

The changes stay within [#24852]. The mobile timeout implements the required reconnect error. The server test covers the viewer attach behavior. The existing read-only viewer test change waits for an asynchronous frame and supports the changed behavior. No unrelated implementation or the separately tracked captureViewport work is included.

Full details: Description check

Explanation

The description clearly explains the problem, implementation, linked issues, verification results, and known limitations. It does not provide explicit maintainer approval for the scope, and it does not include the required before/after UI evidence for the mobile timeout.

Resolution

Add the maintainer approval comment or explain why this focused bug fix qualifies without prior approval. Upload and embed before/after screenshots, plus a short recording if needed to demonstrate the 30-second timeout and reconnect behavior, or explain the applicable exception.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[juliusmarminge]

Closing in favour of #25381, which makes the same change. Thanks for the work here!