Skip to content

fix: wire the mouse side buttons to back and forward - #39

Merged
tobi merged 1 commit into
tobi:mainfrom
fgrehm:fix/mouse-side-button-history
Sep 27, 2026
Merged

tobi merged 1 commit into
tobi:mainfrom
fgrehm:fix/mouse-side-button-history

Conversation

@fgrehm

@fgrehm fgrehm commented Sep 26, 2026

Copy link
Copy Markdown
Contributor

Problem

The README has always documented that the mouse's side buttons retrace the visited directories, and Disktree::on_mouse_down had the two MouseButton::Navigate arms for exactly that. But the mosaic registered its mouse-down listeners per button, for Left and Middle only, so buttons 8 and 9 never reached on_mouse_down and the arms were dead code. The keys (alt ← alt →, ⌘[ ⌘]) and the header < / > buttons worked, which is why this went unnoticed.

Fix

  • Replace the two per-button registrations on the mosaic with on_any_mouse_down, so every button reaches on_mouse_down and the existing Navigate arms work. One listener instead of four, and the per-button form would have needed a registration per button the platform names.
  • Guard the Navigate arms on Screen::Explore, matching the alt-arrow path. On the review screen the marked list is not somewhere history should move.
  • Add a treemap debug selector, so the harness test can aim at the mosaic the way a person aims with the pointer.
  • The help screen and the hover card on < / > named only the keys, so the in-app bindings were narrower than the README's. Both now mention the side buttons.

Verification

cargo xtask ci is green: rustfmt, clippy with the workspace's pedantic and nursery lints at -D warnings, then 55 window-harness tests and 105 core tests.

The new test mouse_side_buttons_go_back_and_forward drives the real window harness: it descends twice, presses button 8 over the mosaic and asserts the crumbs retrace, presses button 9 and asserts they return, then enters the review screen and asserts a further press 8 changes nothing.

That test synthesizes the MouseDownEvent, so it proves the wiring, not that a compositor delivers button 8. gpui-pre does map them: buttons 8/9 on X11, BTN_BACK/BTN_SIDE and BTN_FORWARD/BTN_EXTRA on Wayland, and XBUTTON1/XBUTTON2 on Windows. There is no mapping in gpui-pre-apple, so side buttons stay macOS-dead, where the keys and the header buttons are the whole story.

Checked by hand on Linux (Hyprland) with a real mouse: buttons 8 and 9 retrace the history from over the mosaic, and do nothing on the review screen.

The README has always said the mouse's side buttons retrace the visited
directories, and on_mouse_down had the two MouseButton::Navigate arms for
it, but nothing ever delivered buttons 8 and 9: the mosaic registered
listeners per button, for Left and Middle only. The arms were dead code.

Replaced the two registrations with on_any_mouse_down, so every button
reaches on_mouse_down and the Navigate arms work. One listener rather
than four, and the per-button form would have needed a new registration
for each button the platform names.

Guarded the arms on Screen::Explore, matching the alt-arrow path: on the
review screen the marked list is not somewhere history should move.

The help screen and the hover card on `<` and `>` named only the keys,
so the in-app bindings were narrower than the README's. Both now mention
the side buttons.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants