[Bug]: Mouse thumb (back/forward) buttons navigate the app instead of the in-app browser when the cursor is over the preview

[akosbalogh]

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 a thread and open the right sidebar.
2. Open the in-app browser (preview) on any site.
3. Navigate 2–3 pages deep by clicking links, so the browser has real back history.
4. Move the cursor over the browser page content, but do not click it — leave focus in the host app.
5. Press the mouse thumb/side Back button (the one that goes back in a normal browser).

Expected behavior

While the cursor is over the in-app browser, the thumb buttons should navigate that browser session's history — the same thing the Back/Forward buttons in the preview chrome do.

Actual behavior

The host app navigates back instead: the app router moves between threads/agents, while the in-app browser stays on the same page. It is intermittent in practice because it depends on which surface currently holds focus — clicking into the page first masks it.

Root cause

The preview is an Electron <webview> (apps/web/src/browser/HostedBrowserWebview.tsx) whose WebContents is driven by PreviewManager (apps/desktop/src/preview/Manager.ts).

Chromium's default handling for mouse buttons 3/4 performs a history navigation against the focused/top-level context rather than the guest under the cursor. Because the host renderer holds focus while you are merely hovering the guest, the host app's history is what moves. Nothing in the repo binds these buttons today — there is no auxclick, button === 3/4, or app-command handler anywhere — so this is Chromium's default landing on the wrong target.

Note app-command is Windows/Linux-only and Electron never auto-navigates on it, so this is not the mechanism here; the DOM-level path is. Reproduced and diagnosed on macOS.

Environment

• Platform: macOS
• Area: apps/desktop (preview / in-app browser)
• Any mouse with dedicated back/forward thumb buttons

I have a fix for this in #4459.