Skip to content

fix(desktop): browser view distorts when zoom changes via menu or window resize#2168

Open
benjaminshafii wants to merge 1 commit into
devfrom
fix/browser-view-zoom-authoritative
Open

fix(desktop): browser view distorts when zoom changes via menu or window resize#2168
benjaminshafii wants to merge 1 commit into
devfrom
fix/browser-view-zoom-authoritative

Conversation

@benjaminshafii

Copy link
Copy Markdown
Member

Bug

Reported by a user on X: the embedded browser agent view loads distorted/mis-scaled; cmd+-/cmd+0 temporarily fixes it, but resizing the window (fullscreen → small) re-distorts. Present across multiple versions.

Root cause

Two competing zoom systems. The renderer pre-scales WebContentsView bounds with a cached window.__OPENWORK_ZOOM_FACTOR__ (set only by the app's font-zoom hook), but the native View menu zoom roles (zoomIn/zoomOut/resetZoom — Cmd+-/Cmd+0) change the real webContents zoom without updating that cache. Every bounds sync then uses a stale CSS-px→DIP transform, so the native view renders at the wrong size/offset, and every resize re-applies the wrong transform. PR #2022 added the renderer-side scaling but didn't address the divergence.

Fix

The renderer now sends raw CSS-pixel bounds/points; the main process converts them to window DIPs with the authoritative webContents.getZoomFactor() at apply time (scaleBoundsForZoom/scalePointForZoom in main.mjs), covering show, bounds updates, tab re-attach replay, and the tab context-menu overlay. Any zoom source — menu roles, IPC, future paths — is now automatically correct. The stale __OPENWORK_ZOOM_FACTOR__ global is removed.

Validation (real Electron on Daytona, CDP-asserted)

Sandbox openwork-test-20260610-200725, real workspace + browser panel opened via the automation path (same code path as agent browsing).

Scenario Placeholder (CSS px) Expected view (DIP) dev (before) this branch (after)
zoom 1.0 320×739 320×739 320×739 ✅ 320×739 ✅
zoom 1.25 (menu-role path) 320×575 400×719 320×575 ❌ (floats over chat) 400×719 ✅
zoom 0.8 569×944 455×755 455×755 ✅
resize 1185×845→900×700 at zoom 0.8 405×794 324×635 — (re-distorts per report) 324×635 ✅

Evidence (Daytona artifacts volume, sandbox still running; downloaded locally as backup):

Also run: pnpm typecheck in apps/app (clean), node --check on main.mjs.

Teardown after review: daytona delete openwork-test-20260610-200725 (recordings persist on the artifacts volume).

The renderer pre-scaled WebContentsView bounds by a cached
window.__OPENWORK_ZOOM_FACTOR__, but the native View menu zoom roles
(Cmd+-/Cmd+0) change the real zoom factor without updating that cache, so
the embedded browser view rendered at stale scale and re-distorted on every
resize until zoom was reset.

Send CSS-pixel bounds/points from the renderer and convert them in the main
process using the authoritative webContents.getZoomFactor() at apply time
(show, bounds updates, tab re-attach replay, and tab context menu overlay).
@vercel

vercel Bot commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
openwork-app Ready Ready Preview, Comment Jun 11, 2026 3:36am
openwork-den Ready Ready Preview, Comment Jun 11, 2026 3:36am
openwork-den-worker-proxy Ready Ready Preview, Comment Jun 11, 2026 3:36am
openwork-landing Ready Ready Preview, Comment, Open in v0 Jun 11, 2026 3:36am

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 4 files

Re-trigger cubic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant