[Bug]: Custom viewport size input focus ring is clipped on macOS #13607

Activity

1. juliusmarminge commented on Sep 25, 2026

   

   juliusmarminge

   on Sep 25, 2026

   Member

   More actions

   Triage report: #13607

   Verdict: Valid cosmetic bug. Still present on main (86054b6df2). Not fixed after v0.0.43-nightly.20260925.2237; the toolbar and input files are unchanged since that nightly.

   Severity: Low. Focus, typing, and applying a custom size still work. Only the focus ring is clipped.

   Duplicate: None. Same class of bug as #10175 (file-tree search ring) and #13301 (composer chip rings), different surface.

   What happened

   In the desktop in-app browser, focusing a custom viewport width or height field clips the light purple outer focus ring on the top and bottom. The solid inner purple border stays visible. The field sits against the toolbar’s bottom divider. Reported on macOS with 1920 × 1080 in the height field. Cosmetic only.

   Diagnosis

   The device toolbar is a 32px horizontal scroll container, so it also clips vertically. The size fields are compact inputs whose focus ring is 3px and does not fit in that bar.

   BrowserDeviceToolbar sets height: BROWSER_DEVICE_TOOLBAR_HEIGHT (32) and overflow-x-auto (apps/web/src/browser/BrowserDeviceToolbar.tsx). With one axis auto and the other left visible, CSS computes the visible axis to auto. The bar clips descendant ink, including box-shadows, even when nothing is scrolling horizontally. The scrollbar is hidden; clipping still happens.

   The width and height controls are Input with nativeInput, size="compact", and font="mono". The focus treatment is on the wrapper (apps/web/src/components/ui/input.tsx):

   • Inner border: has-focus-visible:border-ring (the solid purple edge that stays visible).
   • Outer ring: ring-ring/24 plus has-focus-visible:ring-[3px] (the lighter purple ring, drawn outside the border box).

   The inner field is h-7 (28px) and does not shrink at the sm breakpoint (sm:h-7). The wrapper adds a 1px border on every side and no fixed height, so the bordered control is 30px. The toolbar’s 32px height is border-box and includes its 1px bottom border, leaving a 31px content box. A centered 30px control has about half a pixel of room on each side. The 3px ring is clipped on both edges, flush with the divider. That matches the report.

   Neighboring controls are shorter at desktop size, so they are not the ones in the crop. The preset trigger is size="xs" / variant="ghost" (sm:h-6, 2px ring). The lock, rotate, and close buttons are size="icon-xs" (sm:size-6, 2px ring plus 1px offset). Both have enough room in the 31px content box. The numeric fields are the ones that stay 30px.

   This is the desktop Electron host only. ElectronBrowserHost returns null outside Electron, and the toolbar is rendered from HostedBrowserWebview. The CSS is shared, so Windows and Linux desktop builds should clip the same way. The website and mobile app do not mount this toolbar. Settings → Integrations uses NumberField in a normal settings row, not this 32px bar.

   BROWSER_DEVICE_TOOLBAR_HEIGHT also offsets the guest (viewportY) and shrinks the framed area in resolveBrowserDeviceViewportLayout. browserViewportLayout.test.ts expects viewportY: 32 and a framed height of 858 inside a 900px panel (900 - 32 - 10 rail).

   Steps to reproduce

   1. Open the in-app browser in the desktop app.
   2. Turn on the device toolbar (any non-fill viewport, including a custom size such as 1920 × 1080).
   3. Focus the viewport width or height field.
   4. The light outer ring is clipped on the top and bottom; the inner border is not.

   Suggested fix

   Keep overflow-x-auto (narrow panels still need it). overflow-y-visible will not stick beside it.

   Give the toolbar a content box tall enough for a 30px bordered compact input plus a 3px ring on both sides (at least 36px of content, so a border-box height of 37px or more). Bump BROWSER_DEVICE_TOOLBAR_HEIGHT by the same amount and update resolveBrowserDeviceViewportLayout plus the viewportY: 32 test. A CSS-only height change would overlap the guest or leave a gap.

   Shrinking these two fields to h-6 would barely clear the ring and would make the size fields smaller than they are today. #10175 fixed the same pattern by giving the ring room.

   Evidence

   • Toolbar: apps/web/src/browser/BrowserDeviceToolbar.tsx (fixed 32px height, overflow-x-auto, compact numeric inputs).
   • Ring: apps/web/src/components/ui/input.tsx (ring-ring/24, has-focus-visible:ring-[3px], compact h-7).
   • Layout constant: apps/web/src/browser/browserViewportLayout.ts (BROWSER_DEVICE_TOOLBAR_HEIGHT = 32).
   • Nightly v0.0.43-nightly.20260925.2237 and current main match for these files.

   No local patch, commit, or pull request.

   Filed by Grok 4.7 via Cursor.
2. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

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

   acceptedfeature request acceptedfeature request accepted

   on Sep 25, 2026
3. juliusmarminge

   closed this as completedin #16961on Oct 8, 2026