Desktop Browser: page CSS -webkit-app-region: drag turns page content into a bb window drag handle (Linear issue pages unclickable) #5862

Summary

In the desktop app's built-in Browser, any page element styled with CSS -webkit-app-region: drag (or app-region: drag) becomes a drag handle for the whole bb window. Clicks and scrolling never reach the page there; pressing and moving the mouse moves the bb window instead. Regular browsers ignore this property, so sites that also ship an Electron desktop app (they use it for their own title bars) break in bb. Linear is a concrete case: on an issue page the issue body cannot be clicked or scrolled.

Versions and environment

• bb 0.46.1 (desktop app), macOS 27.0.1, Apple Silicon
• main at 9e5c8a9 pins Electron 44.3.0
• Not agent-related: reproduces with no Browser Automation lease on the tab (bb browser tabs reports "control": null)

Steps to reproduce

1. Open a desktop Browser tab in any thread and sign in to https://linear.app.
2. Open any issue page, for example https://linear.app/<workspace>/issue/<KEY>-<n>/....
3. Click into the issue description or the comment box, or scroll the issue body.

Minimal repro, not tested separately; it follows from the cause below. Any page with a drag region should behave the same:

<div style="-webkit-app-region: drag; height: 300px; background: #eee">
  <button>can't click me</button>
  <input placeholder="can't focus me">
</div>

Expected vs actual

Expected: the page receives clicks, focus and scroll, as it does in Chrome or Safari.
Actual:   in the drag region nothing is clickable or scrollable; press-and-move drags the bb window.
          Elements Linear explicitly marks `no-drag` (top bar buttons, the right-hand context menu) keep working.
          The left sidebar and issue lists work because their drag regions are small or absent.

Evidence

Elements with a computed drag region on a Linear issue page (top-level ones only, viewport 946×867), collected with getComputedStyle(el).getPropertyValue('-webkit-app-region'):

DIV._draggableRegion_…   [x 0,   y 0, w 246, h 52]   workspace header in the sidebar
DIV (issue view)          [x 247, y 9, w 691, h 822]  "Creators CRM › Issues › CRE-54 …", the entire issue pane

That page had 1204 elements with a non-none app region in total. Every no-drag descendant matches a control that still works.

Verified workaround: injecting this into the live page immediately restored clicking and scrolling, with no reload:

* { -webkit-app-region: no-drag !important; app-region: no-drag !important; }

Likely cause, inferred and not traced in Chromium: each Browser tab is a native WebContentsView added to the host window's contentView (

Possible fix: force no-drag for untrusted Browser content, e.g. webContents.insertCSS('* { -webkit-app-region: no-drag !important; app-region: no-drag !important; }', { cssOrigin: 'user' }) on every main-frame load (dom-ready) in desktop-browser-view.ts. A web page should never be able to drag the bb window, so this has no legitimate downside. Same-process subframes may need the same treatment.

What you ruled out

• Not a focus or automation issue (Desktop Browser Automation steals focus across BB sessions #3558, Keep keyboard focus off automation-controlled browser tabs #4303, Keep keyboard focus off hidden browser tabs #4310): the tab had no controller lease, and the clicks never reach the page at all.
• Not Plugin overlays render under the native Browser tab view; plugins cannot use the browser-dimming hook #3812 (host overlays under the native view): here the page's own CSS creates the region.
• No existing issue: searched open and closed issues for "app-region" and "drag window browser".

Suggested priority and effort

Medium. It makes Linear issue pages unusable in the built-in Browser, and probably other sites with a desktop Electron app (Slack, Notion, Figma, Discord, ...). The workaround needs DevTools or script injection. Effort probably low: one insertCSS call plus a regression test.

Found in bb thread thr_dtj7t5fs86.

AGENT GENERATED