💭 I'm looking at the changed web files and noting they're focused on viewport CDP override logic rather than any CSS, Tailwind, or shared component changes, so this UI consistency check likely doesn't apply strongly here. Prior runs flagged specific issues — the zoom scaling problem in previewGuestViewport.ts and a devtools detach issue — both of which now appear resolved at the current head commit. I want to check HostedBrowserWebview.tsx directly to confirm no remaining issues with its effect dependencies or webContents gating.

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

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

💭 I'm checking whether prior flagged issues are actually resolved, and looking at the drag case where the viewport ref updates live during pointermove events. The effect keyed on the viewport re-applies on each drag step, so I'm working through whether that CDP override firing every frame is actually safe given the effect's cleanup behavior. For fill mode, clearing the override looks correct, and I confirm the scaled-down webview element width matches what the CDP override sets, so that geometry lines up. But I notice a potential mismatch in fit-source-content mode: the element itself is resized using the fitted viewport, while the guest override still uses the stored effective viewport setting instead — that inconsistency could cause a mismatch between what's rendered and what CDP reports. I'm also questioning the mobile-preset case: the widget element is sized as viewport width times zoom factor, but the CDP override pins the guest's layout viewport to the raw width without that zoom scaling, so the guest and the visible container may disagree on effective size when zoom isn't 1. I'm not fully certain whether mobile emulation actually pins zoom to 1 in Chromium, so I should avoid making a speculative behavioral claim here. Given the review focuses on shared components, styling, and layout preservation, I should instead focus on the concrete fitSourceContent inconsistency where the effect at lines 213-225 uses effectiveViewport rather than the fittedSourceViewport it should be aligned with. Now I want to trace where resolveFittedBrowserViewport and fitSourceContent are actually defined and called from.

3. browse_code — apps/web/src/browser/browserViewportLayout.ts

4. git_tools — fitSourceContent

💭 I'm tracing through the logic: fitSourceContent only applies when the viewport setting is "fill" - otherwise resolveFittedBrowserViewport just passes the setting through unchanged, so the fitted viewport equals the original setting in that case. In fill mode though, the fitted viewport gets derived from the source content size, layout scales down, and the guest override gets cleared - meaning the guest reports its actual element size, effectively mirroring the main player in the mini player scenario. That seems correct behavior. I'm now considering whether ThreadPreviewMiniPlayer, which uses fitSourceContent, could have multiple HostedBrowserWebview instances mounted for the same runtimeTabId, but each tab likely gets just one instance via ElectronBrowserHost. I'm also noticing there could be duplicate application logic between HostedBrowserWebview's own viewport-pushing effect and the agent-driven automation.setViewport path - when an agent resizes, the server snapshot updates and triggers the non-agent path too, which seems redundant but mostly harmless. Since the audit is about UI consistency and the changed files don't touch styling, I'm trying to pin down whether there's a genuine layout regression, especially around what happens when hasWebContents flips to false, like during a webview crash. I'm now working through how zoom scaling interacts with the CSS transform on the webview element - specifically whether the guest's device-independent-pixel size is set to width times zoom while the visual transform separately scales the compositing, which would mean the effective CSS pixel size for the page matches the intended viewport width. For mobile, since emulation pins page zoom to 1, the override needs to be in actual CSS pixels to match the toolbar's viewport width, but this creates a mismatch since the underlying widget itself is sized at width times zoom - meaning the emulated viewport rendered at the override size could leave the rest of the widget area blank unless a scale factor is applied. That would leave a blank region in the top-left corner sized proportionally to the zoom factor. But I should be cautious about claiming this is a genuine regression without evidence — the author added a comment and test for this case, likely after verifying it. I want to check what changed between the prior commit 0ea4e3b and the current 79fa0bd to see if this concern was already addressed.

5. git_tools — 0ea4e3b..79fa0bd

💭 The branch was likely force-pushed, so I should check the PR commit history. I'm also going to look at the changes to PreviewAutomationHosts.tsx since that's the larger web-side modification, so I'll examine that region more closely.

6. browse_code — apps/web/src/components/preview/PreviewAutomationHosts.tsx

💭 I'm checking that setViewport being possibly undefined on older builds is safely handled, even though the type contract marks it required. Then I'm tracing the resize agent flow, where applyPreviewGuestViewport triggers waitForRenderedViewport to confirm the guest's measured size matches the requested setting. I want to look at how isPreviewViewportReady handles a fast path, and also whether HostedBrowserWebview's own reaction to server-driven viewport props could interfere with the agent's zoom-scaled override — need to check waitForRenderedViewport and isPreviewViewportReady directly to see what they compare against.

7. git_tools — isPreviewViewportReady|waitForRenderedViewport|declaredViewport|appliedSettingKey

8. browse_code — apps/web/src/components/preview/PreviewAutomationHosts.tsx

💭 I want to look at the full previewViewportReadiness.ts file to check on the fast path flagged from a prior run.

9. browse_code — apps/web/src/components/preview/previewViewportReadiness.ts

💭 Now that the fast path is removed, I'm scanning for any remaining concrete issue in the web files related to UI consistency or layout preservation—checking whether the viewport effect properly handles fill-vs-non-fill cases, and whether the override gets cleared when a tab is closed or the preview panel unmounts. Tracing further: the zoom ref update during render still works fine with the register effect closure, and fill mode correctly skips when there's no web content. I also check whether HostedBrowserWebview could be mounted twice by a mini-player, but that doesn't seem to happen. The more interesting case is during a resize drag—since the effective viewport updates on every pointermove, the CDP override effect fires each frame, triggering a relayout and IPC call per frame rather than letting the widget just resize naturally. This seems like a perf tradeoff rather than a bug, likely intentional given past complaints about the opposite behavior. There's also a potential double-write between the automation path and the host effect: the agent sets the viewport directly and records a resize action, then the server snapshot updates the viewport prop, causing the same override to be reapplied through the non-agent path. That's redundant but harmless since it's the same value, though I want to confirm the zoom factor source is consistent between the automation path and the component prop—they both seem to pull from the same desktop state, so that checks out. Now I'm turning to whether the check itself should ultimately pass or fail based on whether findings exist. Since there are no real findings, I need to reconcile the instruction to output exactly "All clear" with the requirement to return a JSON-formatted response—I'll follow the system's JSON schema but reflect the no-findings state in the summary field. Before finalizing, I want to verify one more potential inconsistency: whether desktopByTabId is keyed consistently by server tabId versus runtime tabId across different call sites, and it looks like usage in the automation hosts is consistent with keying by server tabId. Now I'm also considering whether subscribing to the entire thread preview state via useThreadPreviewState(threadRef) causes unnecessary re-renders of the webview component on every state change, since other parts of the code use shallow selectors instead—I want to check if this hook supports passing a selector.

10. git_tools — export (const|function) useThreadPreviewState

💭 I notice useThreadPreviewState returns the entire state object, and other components share this pattern too. Subscribing to it fully in HostedBrowserWebview means it re-renders on any preview state change, like navStatus—more a performance nit than a UI-consistency issue. I want to check whether other components in the repo use this hook for narrower fields, just to confirm this is idiomatic usage.

11. git_tools — useThreadPreviewState(

💭 I'm confirming that device toolbar height logic is unaffected, and checking the case where the preview panel is hidden — the webview renders offscreen with the guest override still applied, which matches the intent behind the preview-hidden-viewport fix. I do notice the ref mutations for viewport and zoom happen during render, which is a minor React concurrent-rendering anti-pattern, but not significant enough to flag as a real issue. The diff only touches three web files plus a test, and the test file itself looks fine, including its handling of the undefined viewport case. More importantly, I'm spotting a genuine inconsistency: the web side determines "mobile" using the unscaled setting dimensions before applying zoom, while the desktop side's deviceMetricsOverride determines "mobile" from the already-scaled dimensions it receives. Working through an example — an 800x780 setting at 0.5 zoom is not mobile by web's check but becomes 400x390 after scaling, which desktop then flags as mobile — shows the two mobile decisions can diverge, contradicting the comment that says they should stay in sync. I want to check how realistic sub-1 zoom factors are in practice, since users zooming out the preview would trigger this exact scenario. If mobile emulation pins page zoom to 1, then the CSS size sent by web (768x576) would no longer match the toolbar's 1024x768, breaking readiness checks and reintroducing the exact toolbar/guest mismatch this PR was meant to fix. This is a concrete bug tied to changed lines in previewGuestViewport.ts — the mobile decision needs to be computed consistently on both sides, likely by having web compute mobile from the unscaled CSS value and pass it explicitly rather than letting each side infer it independently. The real issue is that desktop's deviceMetricsOverride computes mobile from the scaled dimensions it receives, while web computes scaling based on its own mobile determination from the unscaled setting — these can diverge whenever zoom is less than 1, since isMobile(setting) may not equal isMobile(setting*zoom). Fixing this properly would mean having the payload explicitly carry the mobile decision, but that touches the IPC contract in packages/contracts, which is out of scope, so there's no clean in-scope fix beyond flagging the divergence. I want to confirm zoomFactor can actually go below 1 in this app, so I need to check where it gets set and whether zooming out is possible.

12. git_tools — zoomFactor

💭 I'm checking whether there's a zoom-out option available in the settings or preview menu.

13. git_tools — PREVIEW_ZOOM|ZOOM_FACTORS|zoomOut|zoom_out|setZoomFactor

14. browse_code — packages/contracts/src/preview.ts

💭 Zoom-out down to 0.25 makes this trivially reachable — even common desktop presets like 1440x900 at 0.8 zoom produce an effective height under 768, triggering the mobile flag. This means almost any zoomed-out desktop viewport could unintentionally switch the guest into mobile device emulation with touch events. But the deeper issue is that mobile emulation pins page zoom to 1, so innerWidth becomes the scaled value (1152) instead of the real 1440 — which breaks the readiness check that waits for the viewport to match, causing a timeout. The correct fix is to compute the mobile decision from the unscaled CSS setting on the web side and pass it explicitly through the override payload, adding a mobile field to the viewport schema rather than inferring it from scaled dimensions. I want to verify the desktop side really derives mobile from the received scaled dimensions via the manager's threshold check against the shortest side, and confirm the zoom factor gets applied to the guest before the override happens — both check out. I'm also weighing whether there's a secondary discrepancy: at non-unity zoom, the widget's CSS-pixel size (setting times zoom) could diverge from the override's raw setting once mobile emulation forces zoom back to 1, so I want to make sure that edge case is accounted for too. I'm now testing the edge case more rigorously — could a preset classified as non-mobile (shortest side ≥768 unscaled) actually cross below 768 once the zoom factor is applied, e.g., 768 at 0.9 zoom giving 691? That confirms the threshold mismatch is a real, provable inconsistency worth flagging, separate from the more speculative viewport-scaling concern I decided not to raise. I'm planning to post a single inline review comment on the relevant lines of previewGuestViewport.ts, targeting the scale calculation and its return statement, after double-checking the corresponding desktop-side logic in the diff to confirm it matches what I described. The comment I'll leave explains that scale is derived from the unscaled setting while the desktop process determines mobile mode from the scaled payload's dimensions, so at zoom below 1 these two calculations can disagree — an iPad-sized viewport gets misclassified as desktop, scaled down, and then incorrectly switched into mobile emulation even though the toolbar still displays the desktop size, causing layout mismatches. I'll suggest fixing this by computing mobile once from the CSS-pixel setting and threading it explicitly through the override payload, extending the relevant schemas so deviceMetricsOverride uses that value directly instead of re-deriving it from post-zoom dimensions. This will be a standalone cross-file suggestion rather than an inline comment. Checking the include patterns confirms previewGuestViewport.ts is covered, and since the file is new, every line including line 32 is part of the diff, so I can leave the comment there. I'll post the review now with a failing state.

15. modify_pr — One finding: the guest/host mobile emulation decision is derived from two different values, so zoomed-out desktop viewports can silently flip the preview into mobile emulation. Details inline.

💭 That awkward parenthetical in my posted comment reads unprofessionally, so I should clean it up by fetching the comment ID and editing it via PATCH.

16. github_api_read_only — repos/{owner}/{repo}/pulls/{pull_number}/comments

💭 My new comment doesn't appear on this page, likely because it's sorted by creation order and mine is newest, so I need to fetch a later page or sort descending to find its ID for editing.

17. github_api_read_only — repos/{owner}/{repo}/pulls/{pull_number}/comments?sort=created&direction=desc&per_page=1

18. modify_pr — PATCH repos/{owner}/{repo}/pulls/comments/3838021716