[Bug]: preview_resize always times out (and evicts the automation host) when the main window is zoomed, because the guest webview reports innerWidth × hostZoom #12319

Activity

1. juliusmarminge commented on Sep 17, 2026

   

   juliusmarminge

   on Sep 17, 2026

   Member

   More actions

   Triage

   Confirmed on current main (4749035bd) and on v0.0.42. This is a real desktop preview-automation bug, not a flake and not already fixed. The report’s diagnosis matches the code, and the measured numbers are exact: zoom level 2.5 is 1.2 ** 2.5 = 1.577440977, and 1280 × 1.577440977 ≈ 2019, 800 × 1.577440977 ≈ 1262.

   What happens

   preview_resize applies the server snapshot, then the desktop renderer polls until the guest CSS viewport matches the request within 1 px:

   const readWebviewViewport = async (
     webview: ExecutablePreviewWebview,
   ): Promise<PreviewRenderedViewportSize | null> => {
     const value = await webview.executeJavaScript(
       "({ width: window.innerWidth, height: window.innerHeight })",
     );
     // ...
   };

     // Electron rounds CSS pixels through the guest's fractional zoom/device scale,
     // so a successfully applied fixed viewport can measure one pixel either way.
     const tolerance = 1;
     return (
       Math.abs(renderedViewport.width - expectedViewport.width) <= tolerance &&
       Math.abs(renderedViewport.height - expectedViewport.height) <= tolerance
     );

   The <webview> is styled to the requested size in host CSS pixels (data-preview-css-width / style.width in HostedBrowserWebview.tsx). Preview-tab zoom is already compensated: layout multiplies the frame by tab.zoomFactor, and assertTabZoom sets the guest to that same factor, so a 1280 CSS request still reports innerWidth = 1280 when the window zoom is 1.

   Window zoom is the opposite. Chromium inherits the embedder zoom onto the guest; desktop then resets it to tab.zoomFactor (default browserDefaultZoomFactor = 1) so the preview “keeps its own zoom”:

       zoomMain: Effect.fn("desktop.window.zoomMain")(function* (direction) {
         // ...
         webContents.setZoomLevel(
           direction === "reset" ? 0 : webContents.getZoomLevel() + (direction === "in" ? 0.5 : -0.5),
         );
         // Chromium pushes the new level down to embedded guests, which would zoom
         // the previewed page along with the app UI. The preview browser keeps its
         // own zoom, so put each guest back where the preview left it.
         yield* previewManager.reapplyZoom();
       }),

     const assertTabZoom = Effect.fn("PreviewManager.assertTabZoom")(function* (tabId: string) {
       const tab = (yield* SynchronizedRef.get(tabsRef)).get(tabId);
       if (!tab || tab.webContentsId == null) return;
       const wc = webContents.fromId(tab.webContentsId);
       if (!wc || wc.isDestroyed()) return;
       yield* attempt({ operation: "assertTabZoom", tabId, webContentsId: wc.id }, () =>
         wc.setZoomFactor(tab.zoomFactor),
       ).pipe(Effect.ignore);
     });

   Same reset on registerWebview (Manager.ts 2190–2196) and on every reapplyZoom (2617–2619). Result with window zoom 1.577 and guest zoom 1: a frame declared 1280×800 occupies ~2019×1262 device pixels, the guest reports that as innerWidth/innerHeight, and the ±1 check can never pass. Existing tests lock this in: previewViewportReadiness.test.ts only allows one pixel of slack; DesktopWindow.test.ts requires reapplyZoom after every zoomMain; Manager.test.ts expects setZoomFactor(tab.zoomFactor) with no window-zoom term.

   This is not Retina/devicePixelRatio as a display scale. On a scale-1 display, renderer devicePixelRatio equals the window zoom factor (the reporter’s 1.5774409770965576). On Retina, devicePixelRatio includes display scale; a default-zoom Retina Mac would already be broken if the guest used full DPR, and it is not. Use mainWindow.webContents.getZoomFactor(), not window.devicePixelRatio.

   Why the host then dies

   waitForRenderedViewport burns the full request budget (default 15 s) and never replies. The broker treats an unanswered deadline as host death:

         const result = yield* Deferred.await(deferred).pipe(Effect.timeoutOption(timeoutMs));
         return yield* Option.match(result, {
           onNone: () =>
             Effect.gen(function* () {
               // An unanswered request invalidates this connection. Do not replay
               // actions: the client may have applied them before becoming unreachable.
               yield* disconnect(connection.clientId, connection.queue);
               return yield* new PreviewAutomationTimeoutError(requestContext);
             }),

   That is the logged Preview automation resize timed out after 15000ms. (PreviewAutomationTimeoutError in packages/contracts/src/previewAutomation.ts), then PreviewAutomationNoAvailableHostError on every later preview_* until the window is reloaded. The host lives only in the Electron renderer (PreviewAutomationHosts returns null when !isElectron), so a zoomed desktop window breaks automation even if the agent is driven from the website.

   Even without automation, the shown “1280 px” page actually lays out at ~2019 CSS px, so device-toolbar breakpoints are wrong whenever the UI is zoomed.

   Not a duplicate

   Issue	Why different
   #12146	Host gone and never re-registers. This issue is a deterministic cause of the 15 s timeout that trips that eviction.
   #12273	A best-effort 500 ms metadata status evicts the host. Same disconnect path, different trigger.
   #11381	Made unanswered-timeout eviction intentional for liveness. Correct for a dead host; not for a resize that can never succeed.

   Keep all three open. Fixing the zoom math stops this hang; it does not restore a host after some other timeout, and it does not make the optional metadata read non-evicting.

   Suggested fix

   Do not only relax isPreviewViewportReady (divide guest innerWidth by window zoom). That would make the wait succeed and leave breakpoints wrong.

   Compensate window zoom the same way preview-tab zoom is already compensated: at assert time, set

   guestZoom = tab.zoomFactor * mainWindow.webContents.getZoomFactor()

   in assertTabZoom / registerWebview.restoreZoomFactor / reapplyZoom. Keep stored tab.zoomFactor as the preview-only setting (default browserDefaultZoomFactor). After that, a 1280×800 declaration stays 1280×800 guest CSS at any UI zoom, preview_resize (freeform, preset, fill) becomes ready immediately, and the visible frame still tracks View > Zoom In.

   Do not use renderer devicePixelRatio as the guest zoom (wrong on Retina). Snap only if Electron requires it; getZoomFactor() already matches the 0.5-level ladder (1.2 ** level).

   Tests to add/adjust:

   1. assertTabZoom / reapplyZoom apply the product, not tab.zoomFactor alone, when the main window zoom is ≠ 1.
   2. Preview-tab zoom 1.25 × window zoom 1.577 still yields guest CSS = requested size.
   3. Keep the existing ±1 readiness tests in CSS pixels; do not widen tolerance to absorb window zoom.
   4. Existing DesktopWindow “restores preview zoom after zooming the app” test can stay; it only asserts reapplyZoom is invoked.

   Workaround

   View > Actual Size (Cmd+0) before preview automation. If the host is already gone, View > Reload (or close/reopen the window). Same as the reporter.

   Labels / next

   • Type: bug (accepted). Desktop zoom assert + tests; no Electron upgrade.
   • Labels: bug, accepted, via-triage.
   • Next: land guestZoom = tab.zoomFactor * mainWindowZoomFactor in assertTabZoom / register / reapplyZoom. Leave [Bug]: Preview automation host disappears mid-session ("No preview automation host is available for <op> in environment …") and never reconnects #12146 (reconnect) and [Bug]: Optional 500 ms preview metadata timeout disconnects the automation host #12273 (non-evicting metadata) as separate follow-ups.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 17, 2026
3. ViaxCo commented on Oct 6, 2026

   

   ViaxCo

   on Oct 6, 2026

   Contributor

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Victor

   Still happens on nightly 0.0.46-nightly.20261005.2702 (macOS, main window zoom 1.5). The saved size is 1280×800, the measured size is 1683×1052, and preview_resize times out. #10536 fixes it in my test on current main: #10536 (comment)
4. juliusmarminge commented on Oct 7, 2026

   

   juliusmarminge

   on Oct 7, 2026

   Member

   More actions

   Obsolete since #15328: preview_resize no longer polls the page's width, so window zoom can no longer time it out or evict the host. The underlying size mismatch under window zoom is tracked in #10525.
5. juliusmarminge

   closed this as not plannedon Oct 7, 2026