[jason5545]

Problem

A snapshot of a hidden preview tab whose fixed viewport is much larger than the window comes back cut off at the bottom. For example, a 1440 × 1700 tab in a 1000 px tall window captures only page y 0–1300. While a capture is pending, the guest sits behind the app at its full viewport size, and Chromium paints a guest only near the window. Details and repro: https://git.cafe/pingdotgg/t3code/issues/26964.

Change

The hidden size of a fixed viewport is capped at the window size, and the existing resolveBrowserViewportLayout fit then scales the guest down, the same way the open panel fits a viewport larger than itself. The guest keeps its CSS viewport, and the snapshot is whole. Because the guest paints at that scale, it is a little softer than a crisp capture. Tabs that fit the window and fill-mode tabs are unchanged.

The hidden-size calculation moves from HostedBrowserWebview to resolveHiddenBrowserViewportSize in browserViewportLayout.ts, so that it can be tested. The component reads the window size through useSyncExternalStore on resize.

Scope and approval

Fixes https://git.cafe/pingdotgg/t3code/issues/26964 (not triaged yet). I believe this fits the small, focused fix exception: one web-only sizing rule for a hidden guest, plus its test. It does not change anything for tabs that fit the window.

Verification

• New case in browserViewportLayout.test.ts: a hidden 1440 × 1700 freeform viewport in a 1400 × 1000 window resolves to 1400 × 1000 and lays out within the window, and a 1280 × 800 viewport keeps its size. It fails on main (88ab83e8bc), which has no capped hidden size. With the change, vp test run src/browser/browserViewportLayout.test.ts passes (3 tests).
• vp run check:changed: format, lint, knip, typecheck (36 packages), the tests beside the change (20 files) and the React compiler check pass.
• Manual: macOS 27.2 (Apple Silicon), vp run dev:desktop, window 1400 × 1000, Browser panel collapsed. Claude Haiku 5.5 ran preview_open (open: false), preview_resize to freeform 1440 × 1700, and preview_snapshot (save: true) on a page of 100 px bands labelled by y.
  • Before, on main: 1280 × 1156, ending at y 1300.
    
  • After: 1280 × 1511, through the last band at y 1600–1700.
    
• Not checked: Windows and Linux, a page zoom other than 100%, and resizing the window while a capture is pending.

Claude Opus 5.5 (claude-opus-5-5) via Claude Code in T3 Code

Fixes #26964

[macroscopeapp]

Approvability

Verdict: Approved at a5716e7

Macroscope's review found this PR approvable — Hidden previews now fit within the window so oversized tabs can be captured without losing their edges. The change preserves configured viewport dimensions and active-preview sizing, with limited presentation-only risk.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Hidden browser viewport sizing now accounts for the current window dimensions. The webview updates those dimensions on window resize, and the layout helper caps configured viewport dimensions to the window.

Changes: Hidden preview viewport sizing

Layer / File(s)	Summary
Resolve hidden viewport dimensions apps/web/src/browser/browserViewportLayout.ts, apps/web/src/browser/browserViewportLayout.test.ts	The resolver caps configured dimensions to the window and retains the fill-mode content, last-rectangle, and default sizing rules. Tests cover oversized and unchanged freeform dimensions.
Use window dimensions in the webview apps/web/src/browser/HostedBrowserWebview.tsx	The webview subscribes to window resize events and passes the current dimensions to the resolver.

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

Change: Bug fix · Severity of issue fixed: Low

Suggested labels: size:S

Suggested reviewers: juliusmarminge, ta-noshii

Merge Risk: Minimal · up to a5716

The reported change addresses hidden viewport capture sizing; no merge-blocking issue is established.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main fix: hidden preview tabs larger than the window now capture the whole viewport.
Linked Issues check		The change addresses #26964. resolveHiddenBrowserViewportSize caps non-fill hidden viewport dimensions at the window dimensions. HostedBrowserWebview uses this size and updates it on window resize…
Out of Scope Changes check		The changes stay within #26964. They move hidden-size calculation into a testable layout function, add the required window-size subscription, and add focused coverage. These changes directly support h…
Description check		The description includes all required sections. It explains the problem and change, links the issue and justifies the focused-fix exception, and reports focused tests, manual results, screenshots, and…

Full details: Linked Issues check

Explanation

The change addresses #26964. resolveHiddenBrowserViewportSize caps non-fill hidden viewport dimensions at the window dimensions. HostedBrowserWebview uses this size and updates it on window resize through useSyncExternalStore. The existing layout fit scales the 1440 × 1700 viewport inside a 1400 × 1000 container while preserving the configured viewport. The new test verifies the large hidden viewport and confirms that a 1280 × 800 viewport remains unchanged.

Full details: Out of Scope Changes check

Explanation

The changes stay within #26964. They move hidden-size calculation into a testable layout function, add the required window-size subscription, and add focused coverage. These changes directly support hidden preview sizing and do not introduce unrelated behavior.

Full details: Description check

Explanation

The description includes all required sections. It explains the problem and change, links the issue and justifies the focused-fix exception, and reports focused tests, manual results, screenshots, and checks not performed.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

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

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 20497e4
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 106a9ec9-0b92-4456-b89c-4324403ad0a4

Commits

Reviewing files that changed from the base of the PR and between 20497e4 and a5716e7.

Files selected for processing: 3

• apps/web/src/browser/HostedBrowserWebview.tsx
• apps/web/src/browser/browserViewportLayout.test.ts
• apps/web/src/browser/browserViewportLayout.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.

[Entrpi]

Measurements for this one, from macOS 26.5 (arm64) with Electron 44.10.1 and a 2560x1600 viewport at page zoom 2 in a 1900x1200 T3 window. Without this PR, a hidden tab's capture came back 2470x1560 instead of 2560x1600. Chromium rasters a child frame only inside its compositing rect (RemoteFrameView::ComputeCompositingRect): the embedder viewport mapped into the frame, plus 15% on each side, with the origin clamped to 0. That's 1.3x the window here.

With this PR the capture is whole. Its fitted guest is scaled down, so it is a bit softer, as you noted. On my fork, which also draws a capturing guest with #31568's full-detail transform, the fitted guest was sharp too: 36 of 36 snapshots at 2560x1600 were whole, sharp and current. That covers light and heavy pages, with the window in front, covered or minimized.

One detail came up there. My fork's covered-window fix (discussed in #23139) draws one pixel of the guest's top-left corner above the app while capturing. Once the fitted guest was centred in its box, that pixel was no longer on the guest. Fitting with one scale for both sides, anchored at the box's top-left corner, fixed it. With main's placement this doesn't come up.