Repository navigation
[Bug]: Horizontal mouse wheel (MX Master thumb wheel) switches threads on macOS desktop #33888
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- macOS desktop app. Open one thread, then another, so history has an entry to go back to.
- Use a mouse with a horizontal wheel (Logitech MX Master thumb wheel).
- Turn the horizontal wheel while the pointer is over the chat or the sidebar, anywhere without a horizontal scroller.
Expected behavior
Nothing happens: there is no horizontal content to scroll. Back/forward by gesture stays a two-finger trackpad swipe; mouse users keep the toolbar buttons and keyboard shortcuts.
Actual behavior
The swipe indicator appears and the app goes to the previous or next thread. It also happens when a horizontal scroll of a wide table or diff reaches its edge.
Impact
Minor bug or occasional failure
Version or commit
main. HistorySwipeNavigation is unchanged there since #28091. The verification on #28370 reproduced the wheel navigation on main at 8b74a69.
Environment
macOS 26.6.2 (Apple silicon), desktop app, Logitech MX Master.
Logs or stack traces
None; nothing is logged.
Recording in #28370 (first 10 seconds: wheel input switches threads).Screenshots, recordings, or supporting files
No response
Workaround
None in the released app. #28370 adds a switch that turns the gesture off.
Context for triage: same root cause as #32955 (Windows tilt wheel). HistorySwipeNavigation treats any pixel-mode, mostly horizontal wheel stream as a two-finger swipe, and Electron gives no trackpad-versus-wheel provenance. #32963 fixes Windows and Linux by limiting the gesture to macOS, which leaves this macOS case open. Other macOS reports of the same: comments on #28370 (MX Master 3S; Magic Trackpad while scrolling).
Activity
Igloczek commentedon Nov 12, 2026
Reproducing the same with an MX Master thumb wheel on the macOS desktop app.
On the approach:
HistorySwipeNavigationrebuilds macOS's two-finger swipe from rawwheelevents. Electron doesn't say whether a wheel stream came from a trackpad or a mouse, and Chromium sendsgestureScrollBegin/Endfor mouse wheels too. So any horizontal wheel input is treated as a swipe, and the code says so itself ("a mouse tilt wheel is indistinguishable from a trackpad swipe"). #32963 fixed this on Windows/Linux by turning the feature off there. On macOS it's still on for everyone, with no way to disable it.Since the app can't tell a trackpad from a mouse, I think this gesture should be opt-in (or off by default), not on for all desktop users. #28370's toggle is a good start, but it ships with the gesture enabled, so every horizontal-wheel mouse user still has to find the setting before the bug stops. Related misfires on trackpads too: #28160, #30160.
shivamhwp commentedon Nov 12, 2026
Handing this issue back to Julius’s existing fix, #33924, at head 3e8b593. It already names this issue as its closing target. Current main still enables HistorySwipeNavigation on macOS; the earlier Windows/Linux platform restriction leaves this report applicable. The existing PR documents Linux wheel reproduction and explicitly leaves macOS hardware verification open. This duplicate automation thread made no code changes and ran no app tests.