fix(browser): open new tabs on Google, auto-open pane, fix view centering - #2020
Merged
Merged
Conversation
…ring Three fixes to the embedded browser panel: - New tabs (the "+" button and opening the browser pane) now load https://www.google.com instead of about:blank. The agent's programmatic path keeps about:blank via BROWSER_DEFAULT_URL. - Opening the browser rail pane auto-creates a browser tab when none exists, so users land on a usable page instead of an empty panel that forced a manual "+" click. - computeBounds no longer multiplies by __OPENWORK_ZOOM_FACTOR__. WebContentsView.setBounds expects content-area DIP, which is the same space getBoundingClientRect() already reports; the extra multiply pushed the native view off-panel at zoom != 1. Width/height are now derived from rounded edges to avoid a 1px seam. getNativeMenuPoint gets the same fix.
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
benjaminshafii
added a commit
that referenced
this pull request
Jun 1, 2026
PR #2020 removed the `* zoom` factor from computeBounds on the incorrect assumption that getBoundingClientRect() already reflects the page zoom in the native coordinate space. It does not. The renderer applies zoom via Electron's webContents.setZoomFactor, which scales the page so getBoundingClientRect()/innerWidth report CSS pixels DIVIDED by the zoom factor (verified live: at zoom 1.5 a 1180 DIP window measures innerWidth 786). WebContentsView.setBounds, however, expects window device-independent pixels — a fixed 1180-wide content area that does not change with zoom. So renderer rects must be multiplied back by the zoom factor to map into the native space. Restore the multiplication (keeping the rounded-edge width/height that avoids a 1px seam). At zoom = 1 the result is identical to before. Verified live via CDP at zoom 1.0 and 1.5: the native view's left/right edges and top exactly match the panel chrome (leftAligned/rightAligned true, chrome-bottom-to-view-top gap 0), and bounds auto-resync on zoom change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Three issues reported with the embedded browser/artifact panel:
about:blank— the user wanted a real site (Google).+. Opening the browser pane (Globe rail button) showed an empty panel; you had to manually click+to get a tab.WebContentsViewwas mis-positioned within its panel.Root cause
1/2. New-tab default was hardcoded to
about:blank, andopenBrowserRailPaneonly toggled the panel open without ever creating a tab.computeBoundsmultiplied the measured rect bywindow.__OPENWORK_ZOOM_FACTOR__. ButWebContentsView.setBoundsexpects device-independent pixels relative to the window content area — exactly the spacegetBoundingClientRect()already reports (renderer zoom is already baked into the layout it measures). The extra multiply applied zoom twice, pushing the native view down-and-right and oversizing it (a no-op at the default zoom of 1, but broken for font-zoom users). Independent rounding of x/width also left a possible 1px seam.Fix
apps/desktop/electron/main.mjs: addBROWSER_NEW_TAB_URL = "https://www.google.com"and use it for user-initiatedcreateTab(the+button / opening the pane). The agent's programmatic path still usesabout:blankviaBROWSER_DEFAULT_URL.apps/app/.../chat/session-page.tsx:openBrowserRailPaneauto-creates a browser tab when opening the pane and none exists, so the Globe button lands you on Google instead of an empty panel.apps/app/.../panel/utils.ts: drop the spurious* zoomincomputeBounds(andgetNativeMenuPoint); derive width/height from rounded edges to avoid a 1px seam. Correct at zoom=1 (identical numbers) and fixed for zoom≠1.Testing
pnpm --filter @openwork/app typecheck→ exit 0.Verified live in the running Electron app via CDP (after restarting the desktop dev process so the
main.mjschange took effect):tabs: [{ url: "https://www.google.com/" }]with one auto-created tab. (Confirms Idea: Rename into Labori #1 + Minor issue in README: audience description is an incorrect generalization #2.)computeBoundsreturned{x:656, y:81, width:480, height:739}— clean integers; the native view sits flush against the panel divider on the left and leaves exactly the 44px (w-11) rail gap on the right. (Confirms Add engine doctor + guided OpenCode install #3.)Screenshot of the working panel (tab "Google", URL bar
https://www.google.com/, nav chrome, content region aligned to the panel):Reproduce
pnpm devhttps://www.google.com, and the browser view fills the panel cleanly (no offset).Notes
__OPENWORK_ZOOM_FACTOR__global is still set byfont-zoom.tsand kept in the type decl; left untouched to keep the diff minimal.