fix(desktop): back/forward via keyboard chords, mouse X1/X2 buttons, and swipe gestures

[matheuskiser]

Problem

Two related gaps in global back/forward navigation. Fixes #3775.

1. The keyboard shortcuts almost never fire in real use — users fall back to clicking the toolbar chevrons and assume the shortcuts don't exist.
2. On macOS, mouse back/forward buttons (X1/X2) and horizontal swipe gestures do nothing, although they navigate in every browser and in Slack.

Duplicate check: searched open PRs and issues — none found beyond #3775 (filed alongside this fix). #3078 / #3377 are next/previous-channel navigation, a different feature.

Root causes

Keyboard: useBackForwardControls's keydown handler bailed whenever the event target was editable — but useComposerAutofocus deliberately focuses the message composer (a ProseMirror contenteditable) on mount and on every channel switch. In steady state focus almost always lives in the composer, so the chords were silently swallowed. Invisible to CI because navigation.spec.ts only ever clicked the global-back / global-forward buttons, never pressed the keys.

Mouse/swipe: on macOS, WKWebView never delivers X1/X2 button events or swipe gestures to the page (Safari handles them natively in the app layer, not in page JS), and Buzz had no native handler.

Fix

Keyboard chords (web layer)

Match the existing platform chord regardless of the event target and drop the editable-target guard:

• ⌘[ / ⌘] have no text-editing semantics in macOS text fields, and the TipTap/StarterKit editor config binds no Mod-[ / Mod-] shortcuts (checked useRichTextEditor.ts — list indentation is Tab/Shift-Tab).
• preventDefault() keeps the chord out of the editor — asserted in the e2e test.

This matches browsers and Slack, where back/forward chords work while a text field is focused. Chord matching is extracted into a pure helper, app/navigation/backForwardChords.ts, so it can be unit tested; behavior (bindings, modifier exclusivity, code-based matching for non-US layouts) is unchanged.

macOS mouse buttons and swipe gestures (native layer)

An NSEvent local monitor in mouse_nav.rs catches what the webview can't see and emits a mouse-nav Tauri event to the main window (emit_to, so navigation stays scoped if multi-window ever lands) that the frontend acts on. Two AppKit event shapes map to navigation:

• otherMouseUp with button 3/4 — mice whose X1/X2 buttons arrive as plain button events. These are swallowed after emitting so nothing downstream double-handles them.
• swipe with a horizontal delta — AppKit's page-swipe gesture (swipeWithEvent:): deltaX > 0 back, deltaX < 0 forward. Sent by mouse drivers that synthesize a page-swipe gesture for the back/forward buttons instead of button-3/4 events (the hardware this was verified on). Stock Apple trackpad and Magic Mouse swipes arrive as phased scroll-wheel events instead, which this PR does not handle — that path (ScrollWheel + trackSwipeEventWithOptions:, which also needs scroll-edge detection) is deferred to a follow-up. Swipes are passed through (swallowing mid-gesture events could confuse AppKit gesture tracking).

The swipe path was verified end to end on hardware whose back/forward buttons emit only swipe gestures, never button-3/4 events — an instrumented event monitor confirmed the events arrive as NSEventType::Swipe with deltaX ±1, and navigation worked after mapping them.

Tests

• 13 unit tests for the web-side chord matcher (backForwardChords.test.mjs): supported chords, modifier exclusivity, code fallback, and preservation of line-editing shortcuts.
• 6 Rust unit tests for the native mapping helpers (mouse_nav.rs): button 3/4 directions, other buttons ignored, swipe delta sign → direction, zero-delta (gesture-begin) ignored.
• e2e regression case in navigation.spec.ts: presses the platform chord while the composer is focused — the missing coverage. Verified it fails against the pre-fix implementation and passes with the fix.
• Full desktop unit suite: 3832/3832 pass. Full Rust suite (cargo test, buzz-desktop): 1888 passed / 0 failed. pnpm typecheck, biome check, pnpm check, cargo fmt --check, cargo clippy: clean (no new warnings).
• Full Playwright e2e: 958 passed; 6 failures are relay-infrastructure tests (live relay seeding / relay state seam) that fail identically without this change — navigation.spec.ts is fully green.

Manual test

1. Open a channel, then another (composer autofocuses on each switch).
2. ⌘[ — returns to the previous channel; ⌘] — forward again. Typing [ / ] in the composer inserts normally.
3. Mouse back/forward buttons navigate the same way, from anywhere in the window (verified on macOS on hardware using both event shapes).

Update — 2026-07-31

Removed the redundant DOM mouse-button handler after verifying it was unnecessary. The native macOS path remains unchanged and was revalidated manually.

[Chessing234]

thanks for covering mouse back too. one ask — keep editable targets from eating cmd-left/right so line-start editing still works

[matheuskiser]

thanks for covering mouse back too. one ask — keep editable targets from eating cmd-left/right so line-start editing still works

@Chessing234 good call, but this PR doesn't mess with those command shortcuts. I added a test and validated in the dev env.

[wpfleger96]

🤖 synthesized findings from two independent agent reviews at head 04917b4 (full write-up in our review channel). the keyboard-chord half of this PR is clean — chord matching in a pure helper with modifier-exclusivity tests, the editable-target guard removal is correctly argued, and the e2e regression test reproduces the exact bug. the inline comments below are about the native gesture layer and the unverified Windows path: one blocking gap on the macOS swipe event class, one pre-merge Windows verification ask, and three nits.

[wpfleger96]

🤖 I verified the changes at 08abf603a — the macOS scope is now accurately documented with the ScrollWheel + trackSwipeEventWithOptions: path deferred to a follow-up, the Windows mouseup handler removal checks out (no dangling references to matchBackForwardMouseButton or the listener), both emits are scoped to the main window, and the test counts line up. Also ran the desktop unit suite, the Tauri Rust suite, and typecheck locally at this exact commit — all green.

Approving. Note the full CI workflows haven't run on this head yet, so we'll still need those green before merge.