fix(server): preview resize and status report the real size of desktop tabs#32854

Problem

In the desktop app, preview_resize always returns a viewport of 1280x800 for a Browser panel tab, whatever size the agent asked for. preview_status can also report an old size after a resize that the page has already applied, for example the previous fill size after a freeform resize. Agents then make layout decisions from a size the page does not have.

The cause: in the desktop app the server drives each tab over CDP, and the desktop draws it in a webview. Playwright has no viewport for those pages, so page.viewportSize() is null and the resize result falls back to 1280x800. Status measures innerWidth/innerHeight in a new isolated world on every call (three CDP round trips). When that read fails, or runs before the desktop has drawn the new size, status quietly returns the last cached size.

Change

The source changes are in apps/server/src/preview/ServerBrowser.ts, plus one field made optional in packages/contracts/src/previewAutomation.ts. They apply only to desktop-drawn tabs (tab.desktop !== null). Playwright-owned tabs keep their current code paths.

• Status keeps the measured size and reads again only when it is stale. The existing Page.frameResized, Page.loadEventFired and Page.javascriptDialogClosed listeners now also set a stale flag. A read that fails or measures 0x0 leaves the flag set, so the next status retries. A status that arrives while a read is running waits for that read, so it does not answer with the size from before it. If the page resizes or loads during that read, status reads once more. This holds for fixed settings (freeform and preset) too, because a page can keep another size than the one asked for: in #22942 a tab kept 560x760 after an 844x390 request. When the user changes the setting (device toolbar or a viewer), the resized handler now records it as soon as the session event arrives. Before, it waited behind any running agent action in the tab's control queue.
• Resize waits for the desktop to draw, then measures. Before it publishes the new setting, the op captures a promise that the page's next Page.frameResized settles. When the CSS size changes, it waits for that resize. This gives desktop tabs the same timing as Playwright tabs, where setViewportSize is awaited, so the agent's next snapshot sees the new size. The wait is bounded by min(1 s, half the time left before the request's deadline). The op then reads the page even if no resize arrived, within the rest of that time. It reports that size only when the read succeeds and no page resize or load arrives during it. Otherwise the result has no viewport, as status already does when it has no measurement. Before, a failed read gave the last measured size, or 1280x800 on a tab that was never measured. So the op always answers before its request's deadline, even after waiting in the tab's control queue, and it cannot trigger the broker's host eviction. To do this, executeTabOperation now takes the deadlineMs that its callers already have.

Eager size pushes to remote viewers of desktop tabs (web or mobile clients watching the desktop's server) are unchanged. With no viewer, a page resize only sets a boolean and settles a promise. So a user dragging the panel costs nothing until the next status.

Side effect: status on a desktop tab now makes no CDP calls unless the page changed since the last read. Before, every status (and every op that returns status) made three round trips and created a new isolated world.

One contract change: viewport in PreviewAutomationResizeResult is now optional, like viewport in status. No client reads it. Agents see it only in the preview_resize result. There are no UI changes and no changes to tool descriptions or input schemas. Otherwise only the numbers in the viewport fields of preview_resize, preview_status, preview_open and preview_navigate become correct.

Scope and approval

Fixes #22942. It also fixes the resize half of #32292 and #32341 ("setting 1440x900 but viewport 1280x800").

This is a small fix for an obvious bug: preview_resize reports 1280x800 for every desktop tab, and preview_status reports a stale size. It is server-only: one source file, one test, and one contract field made optional. #22942 asks that a resize that cannot confirm its size say so, not report fallback dimensions; the optional viewport does that. It changes no default, setting or tool text. The one timing change is the bounded wait in resize, which matches what Playwright tabs already do. Every client and provider uses the same service path, so no per-client or per-adapter change is needed. Servers reached over remote, relay or tunnel use Playwright tabs and are not affected.

#22954 fixes the same bug another way. It measures right after the resize without waiting for the desktop to draw, and adds an optional confirmed field and new tool text, so a resize often answers confirmed: false with the old size. This PR waits for the draw, reports the measured size, leaves it out when there is none (no new field and no tool text change), and also fixes the stale status. If you prefer #22954, I'll close this one.

Verification

Base: upstream main 09a54f01bc. Main was merged in later: the maintainer pipeline's 43f9865530, then 674c7b2c82 and dc48eb84a5 (main 08930cafe3).

New test: apps/server/src/preview/ServerBrowser.test.ts > "a desktop tab reports the size the desktop draws after a resize". It sits next to the existing "desktop viewers get the page's CSS size and keep the last one a read cannot measure" and reuses its mocks, with no viewer attached. It forks the resize, waits for the resized session event, sets the mock page size and emits Page.frameResized. There are no sleeps, clock adjustments or polling. Steps:

1. On a fresh tab whose size reads all fail, a freeform 900x600 resize returns no viewport.
2. A freeform 1280x760 resize returns 1280x760.
3. Status returns 1280x760 while every page size read fails, because nothing changed since that read.
4. A freeform 1000x700 resize whose read fails returns no viewport, not the last measured 1280x760.
5. A freeform 844x390 resize whose page keeps 560x760 returns 560x760, and so does the next status.
6. A resize to fill returns the measured 1234x700.
7. A later status returns 1234x700 and makes zero page reads.
8. A status that starts while a fill read is in flight waits for it: status and the resize both return 1100x650.
9. The page resizes during a read that a status waits for. Status reads again and returns 1000x600, and the resize that started the read returns no viewport.
10. A page load lands during a read that a resize and a status wait for. Status reads again and returns 900x560, and the resize returns no viewport.

Results:

• On main it fails at step 1: expected { width: 1280, height: 800 } to be undefined. Only this test fails.
• The first commit of this PR (cfad2c4332) fails at step 1 with the same message.
• Mutation checks of the second commit: without the extra status read, step 9 fails (expected { width: 1100, height: 650 } to deeply equal { width: 1000, height: 600 }). Without the page-resize check in resize, step 9 fails (expected { width: 1100, height: 650 } to be undefined). With the cached size as a fallback after a failed read, step 4 fails (expected { width: 1280, height: 760 } to be undefined).
• Mutation checks of the fourth commit (ea0fbce3cd, from review): without the change in status, step 10 fails (expected { width: 1000, height: 600 } to deeply equal { width: 900, height: 560 }). Without it in resize, step 10 fails (expected { width: 1000, height: 600 } to be undefined).
• Step 5 fails against an earlier version of this branch that answered fixed settings from the setting: expected { width: 844, height: 390 } to deeply equal { width: 560, height: 760 }.
• Step 8 fails against an earlier version in which status answered from the cache during a read (1234x700, not 1100x650).
• With the fix, ServerBrowser.test.ts passes (64 of 64, merged with current main).
• A fresh vp run check:changed on the merged branch passes: format, lint, knip, graphql, typecheck of 37 packages, and the tests beside the changed files (2 files, 66 tests).
• Evals: none. No tool description, input schema or error text changes. The preview_resize output schema now marks viewport optional and says when it is left out. agentContextBudget counts only tool names, descriptions and input schemas, so its values do not change (AgentContextBudget.test.ts passes). A fake-thread eval cannot exercise desktop-drawn sizing.

Desktop app check: a dev desktop build of an earlier version of this branch (fixed settings answered from the setting), together with other preview fixes, driven by a scripted agent turn. On a desktop-drawn tab, the agent resized to freeform 1280x760, then to the Pixel 7 portrait preset, then to fill. After each resize it read ({ w: innerWidth, h: innerHeight }) with preview_evaluate. Each resize result and the next preview_status matched the page: 1280x760, then 412x915, then 412x915. On main every one of these resize results is 1280x800. The tab was not on screen in that run, so fill kept the last drawn size, and the fill resize answered after its 1 s bound. I did not rerun it for the second commit, which only changes what a resize or status reports when a read fails or overlaps a page resize.

Not covered by a test: the timeouts of the draw wait and of the read after it, and the early tab.setting assignment in the resized handler. A deterministic test of either would need a marker for "the op is now waiting" or a polling step. The code has no such marker, and the repo's test rules forbid polling. Not checked live: a tab that is on screen while the panel is dragged, and a change of the preview zoom.

Questions for maintainers

• The second commit makes viewport optional in the resize result, as #22942 asks and review requested, and the third describes the field. If you would rather keep the contract unchanged, I can drop both. The resize would then report the last measured size, or 1280x800 for a tab that was never measured.
• I did not check whether Chromium sends Page.frameResized when only the preview zoom changes. If it does not, status keeps the pre-zoom size until the next page resize or load. A follow-up could mark the size stale when the desktop finishes applying a zoom. Marking it stale on the resized session event does not work: that event arrives before the desktop draws, so an early read would store the old size again.

Built with Claude Opus 5.5 in Claude Code (run from T3 Code); the first commit was reviewed by GPT-6 Astra in Codex.