Investigation · Desktop / Browser pane

Why clicking inside a browser pane doesn't highlight it

A click-to-focus regression traced, fixed, and verified over CDP — plus a second, unconfirmed hypothesis about the close button that didn't hold up under repro.

01What regressed, and why

Clicking anywhere in a pane is supposed to activate it — standard IDE behavior, enforced by one onMouseDown on the pane's own wrapper (packages/panes/.../Pane.tsx). That works for ordinary pane content. It never worked for a browser pane's page content, and the reason is structural, not a one-line bug.

A browser pane's <webview> is deliberately hoisted to a single body-level container (browserRuntimeRegistry.ts), positioned over its placeholder with position: fixed. That's been true since the browser pane was first ported to v2 (v2-workspace, "port browser pane to v2 workspaces with global persistence") — reparenting an Electron <webview> destroys and respawns its guest process, so keeping it fixed under <body> is what lets a page survive tab switches and splits without reloading. The side effect: the webview is no longer a DOM descendant of the pane wrapper that owns activation, so a click inside the page never bubbles a mousedown to it.

The identical bug existed for PagePane (published-page iframes) and was fixed three days earlier — the fix comment says it outright:

// Make this the active pane. Clicking anywhere in a pane activates it,
// but a click inside the page's iframe never reaches the pane's own
// handler, so the frame reports it and the pane activates itself.

That fix works because PagePane's iframe runs Superset's own code, which can cooperatively postMessage a pointer-down event to the host. A browser pane's <webview> hosts an arbitrary third-party site — it can't be made to run that script. The equivalent fix for browser panes was never written, so the gap sat there until it became visible next to its now-fixed sibling.

02The fix

Electron's WebContents exposes a focus event specifically documented for detecting focus moving between different WebContents in the same window — the same signal the existing zoom-hotkey code already reads via document.activeElement. That's the host-side hook: no injected script, no cooperation needed from guest content.

+ private setupFocusForward(paneId: string, wc: Electron.WebContents): void {
+   const handler = (): void => {
+     this.emit(`pane-focus:${paneId}`);
+   };
+   wc.on("focus", handler);
+   this.focusListeners.set(paneId, () => wc.off("focus", handler));
+ }

+ onPaneFocus: publicProcedure
+   .input(z.object({ paneId: z.string() }))
+   .subscription(({ input }) => observable<void>((emit) => {
+     const handler = () => emit.next();
+     browserManager.on(`pane-focus:${input.paneId}`, handler);
+     return () => browserManager.off(`pane-focus:${input.paneId}`, handler);
+   })),

+ const paneFocusSub = electronTrpcClient.browser.onPaneFocus.subscribe(
+   { paneId },
+   { onData: () => ctxRef.current.actions.focus() },
+ );

Typechecks clean. Confirmed the mechanism end-to-end over CDP: clicking inside the webview does move host-side DOM focus onto the <webview> element (document.activeElement.tagName === "WEBVIEW"), which is the same signal path the zoom hotkeys already depend on. What I could not get a clean visual read on is below.

Why the visual confirmation is inconclusive

Electron's WebContents focus/blur events fire for focus moving between WebContents in the same window — which presumes the window itself holds real OS focus. Driving a background dev window purely over CDP never gives it that: document.hasFocus() read false through every attempt below, even as the click visibly landed in the guest.

03The close-button hypothesis

Question on the table: does a browser pane's header × fail to close it when the pane isn't the active one in a split? Traced the code first — the close button lives inside the same wrapper that has onMouseDown={context.actions.focus}, so a click there should activate-then-close on every press, regardless of prior state. Reproduced it live to check, three times, twice with a naive CDP click and once with the corrected recipe (buttons:1 + pointerType:"mouse" on press/release, socket held open past the dispatch — a synthetic click can silently no-op without both).

• Browser + terminal split, terminal active, browser's own header × clicked directly → closed.
• Independent repro, same shape, fresh session → closed.
• Third repro with the corrected CDP click recipe (see below) → closed, filmed.

Didn't reproduce. Either it needs a shape I haven't hit — two real browser panes side by side rather than browser+terminal (the pane-registry's split action defaults to a terminal regardless of source kind, so I couldn't get two live webviews into one split without a drag-to-merge I didn't get to), a specific build, or a genuine mouse click rather than CDP input — or it's an intermittent miss on the small target next to it (next section). Left alone until it's reproduced live.

04Button size

Measured the browser pane's header icons directly from the DOM, not by eye:

18px targets with a 2px gap between two different actions is tight for a desktop pointer — enough that an imprecise click on close could land on split instead. That wouldn't explain a failure conditioned on active/inactive state, but it's worth widening the hit padding regardless, independent of whether the close-button hypothesis above ever reproduces.

05Narrow panes: bigger icons, no overlap at any width

Widening the icons directly (04) broke a narrow-pane fix. The real cause turned out to be older than that change, and the layout is now guarded so no header width can produce an overlap.

Root cause

apps/desktop's Tailwind @source scanned the renderer and packages/ui but never packages/panes. So PANE_MIN_SIZE_CLASS_NAME's min-w-[260px] (defined only in panes) was never generated — computed min-width: 0px — and a pane could be squeezed to ~67px, where no icon row of any size fits. One @source line activates the existing minimum; the only utilities that newly activate are min-w-[260px] and min-h-[160px].

Guards, in priority order

The header is a named @container/pane-header, matching how the diff header and Open-in button already collapse by their own width rather than the viewport.

CDP audit (real layout, DPR 2)

For each viewport width, every header button's visible rect (its layout rect clipped by overflow-hidden ancestors) is checked pairwise for intersection, for escaping its header, and the header for horizontal overflow. Emulated widths 1728 → 520px, browser + terminal split.

06Regression caught: the container hid the URL suggestions

Reported from a screenshot: with a query typed in the browser pane's URL bar, the suggestion list rendered clipped and under the Import banner.

@container applies CSS layout containment, and layout containment makes the element its own stacking context. The suggestion list is a plain absolute … z-50 box inside the header, so once the header was the container its z-50 only counted inside the header — the banner, a later sibling outside it, painted on top.

Fix: the container now lives on the pane root, which has the same width (so every @min-[…]/pane-header query is unchanged) and whose stacking context holds both the header's popovers and the pane's banners — the same z-order as before this work.

07Full-surface sweep, and a second bug it caught

Rule from this thread: check everything the change can touch, every time. So the header work now ships with a nine-surface CDP sweep — and running it found a real defect in the click-to-activate fix itself.

The bug: the mousedown watch did not survive a navigation. The executeJavaScript awaiting a click in the old document is orphaned when the guest navigates — it never rejects, it just never settles — so the loop parked on it forever. On the new page the guest showed hookInstalled: false; clicking the page no longer activated the pane. The earlier test plan claimed the opposite; it had not actually been exercised.

The fix: dom-ready starts a fresh loop per document under a generation counter; a stale loop exits at its next check and a late resolution is dropped. After navigating example.com → example.org the guest reports hookInstalled: true.

08URL suggestions under the page — pre-existing, now fixed

Second screenshot report: with the banner fixed, the suggestion list still got cut off where the page began. Before touching it: was this the container move, or older?

Same result either way: pre-existing. The list was an absolute z-50 box inside the header, and the hoisted native <webview> paints over the entire pane tree — no z-index inside can beat it. That is the exact class #7232 solved by moving the find bar, composer and error state into the registry's overlay layer; the suggestion list was left out.

Fix: the list portals into that overlay (the host layer mirroring the page rect, painted above the webview), placed at the input's edges in the layer's coordinates and re-measured while open (ResizeObserver on the input and the overlay). It falls back to the in-place list until the pane's overlay is attached. Its top clamps to the overlay's edge, so with a banner present it starts just under the banner instead of overlapping it.