fix(preview): resize hidden browser tabs reliably - #8469

💭 I'm identifying the relevant files within scope, focusing on the browser and preview automation components in the web app that were changed. This PR is purely about viewport state logic, so I'm confirming there's no CSS, shared component, or theme changes to worry about. Checking environment routing, PreviewAutomationHosts resolves the environmentId explicitly from host props, which looks correct. I'm also examining HostedBrowserWebview for React anti-patterns, noticing that assigning to guestViewportRef during render rather than in an effect could be a concern. Given the check's narrow scope, it seems like there are no real findings here, and since the check defaults to failure but expects "All clear" when nothing is found, I'll need to represent that outcome within the required JSON output structure. I want to double check by looking at HostedBrowserWebview.tsx around the changed lines to confirm nothing UI-breaking exists with hasWebContents usage.

1. browse_code — apps/web/src/browser/HostedBrowserWebview.tsx

2. browse_code — apps/web/src/components/preview/previewGuestViewport.ts

💭 I'm checking whether fill mode with fitted source content might create a mismatch between the CSS-sized webview element and the device metrics override, since applyPreviewGuestViewport relies on the effective viewport rather than the fitted one. Then I consider whether recomputing the CDP override on every pointer move during a drag could be a performance concern, though it seems intentional for live resizing rather than a genuine bug. I also note the ref mutation during render is technically unconventional under React 18 concurrent rendering, but it still works functionally and isn't flagged by the stated rules. I turn to environment routing: previewBridge is a desktop-level global keyed by runtimeTabId, distinct from the server-side environment routing that PreviewAutomationHosts handles explicitly, so that's not a conflict. What catches my attention is that hasWebContents is looked up from desktopByTabId using the server tabId, while the viewport is applied using runtimeTabId — I want to check whether that keying is consistent with how desktopByTabId is used elsewhere in the codebase.

3. git_tools — desktopByTabId

💭 I'm checking whether subscribing to the entire thread preview state in useThreadPreviewState causes unnecessary re-renders, but comparing against PreviewView.tsx's usage suggests this is actually the common pattern here, so it's likely fine. I want to look at PreviewAutomationH next to confirm. Checking that ready.bridge.setViewport is properly typed on DesktopPreviewBridge — it is. The removal of automation default resize logic seems fine too, since previewAutomationOpenViewport is only called for new tabs, not reused ones, matching the prior behavior. Overall this PR looks like state/plumbing work rather than UI, so I don't expect styling concerns, though I want to double check the effect dependency on normalizedZoomFactor against the ref read timing, and look more closely at the registration path in HostedBrowserWebview for a possible real bug. Now I'm considering whether forcing the CDP viewport override to effectiveViewport could conflict with fitSourceContent mode, where the guest's CSS layout previously matched the fitted element size rather than the raw viewport — this could be a genuine regression if the override now dictates a different layout size than what fitting intended.

4. git_tools — fitSourceContent

5. git_tools — resolveFittedBrowserViewport

💭 I'm tracing how fitSourceContent only kicks in for fill viewports with mini-player mode, where layout uses a fixed size derived from source content while the guest's CDP override gets cleared so it falls back to the layout's own viewport dimensions. Working through the fixed-viewport case, the element's CSS size matches layout.viewportWidth/scale consistently with the CDP override, so there's no conflict there either. Live drag resizing does trigger the CDP override on every frame, which could be costly but seems intentional for live reflow, so overall I don't see any UI consistency issues to flag here -- everything checks out clean.