Sign up
View stargazersSign up

[Bug]: Clicking off browser menu does interact properly (nightly)#18729

openedOct 12, 2026byTtheDanielJLewis

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. Open the in-app browser and navigate to any page.
  2. Click the three-dot menu.
  3. Click in the browser viewport and the menu remains open and continues to remain open as you navigate the website.
  4. Click in the browser address bar and the menu closes, but the address bar doesn't receive focus.
  5. Click in the empty tab area and nothing happens.

Expected behavior

First, I expect clicking anywhere outside the menu would close the menu.

Second, I expect that click to be respected instead of only functioning to close the menu. For example, focusing in the address bar or pressing a button in the webpage.

Actual behavior

Clicks within the viewport do affect the webpage, but do not close the menu.

A click in the address bar does close the menu but does not activate the address bar.

Impact

Minor bug or occasional failure

Version or commit

0.0.46-nightly.20261012.3021 (7b6d90757415)

Environment

macOS 26.6.2 (Intel)

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

I have to click in an unexpected place or manually close the menu like it's 1992.

JJulius MarmingeOct 12, 2026

Note

Grok responding on behalf of Julius.

The viewport half of this is a bug. It looks like a regression of #11148, so I'm keeping it open. The address-bar half is intended.

Viewport click doesn't close the menu. #11148 (merged Sep 22, fixing #11137) handled exactly this. A click inside the guest page only reaches the app as a focus event on the <webview>, so HostedBrowserWebview replays a pointerdown on that focus to trigger Base UI's outside-press dismissal. That code is still on main and in your build (0.0.46-nightly.20261012), so something is stopping it from firing for the three-dot menu (PreviewMoreMenu). Since that fix, #15328 (Oct 6) and #17316 (Oct 8) reworked how browser tabs are hosted, and they're the likely suspects. We haven't confirmed the exact cause yet.

Address-bar click only closes the menu. This is intended. App menus are modal (the Base UI default), so the first click outside a menu dismisses it and isn't passed through to whatever is underneath. Every menu in the app works this way.

For now, press Esc or click the ⋮ button again to close the menu.

JJulius Marminge20d ago

Reproduced the address-bar first-click failure on main at a50cd989ae in the Linux web client (1440×900): opening the Browser menu and clicking the URL field closes the menu but returns focus to its trigger. Clicking empty tab-strip space closes the menu. The native macOS viewport behavior is not verified here. The separate guest-click path is covered by #23143.