Mouse tilt-wheel horizontal scrolling switches threads on Windows desktop (treated as a trackpad swipe)#32955

opened3d agobyBBishi

What happened

On the Windows desktop app, using a mouse's tilt wheel (Razer mouse, tilt mapped to "Scroll left/right") anywhere without a horizontal scroller (thread chat, left sidebar, right sidebar) briefly shows the back/forward swipe arrow, then navigates to the previous/next thread.

Where a horizontal scrollbar exists, the tilt correctly scrolls it and no arrow appears.

Expected: horizontal mouse wheel input never triggers history navigation, while horizontal scrolling of scrollable content keeps working.

Diagnosis

HistorySwipeNavigation (apps/web/src/components/HistorySwipeNavigation.tsx), mounted for every Electron platform (AppSidebarLayout.tsx:478), classifies any pixel-mode wheel stream whose horizontal component dominates as a two-finger trackpad swipe, and navigates once accumulated deltaX reaches SWIPE_TRIGGER_DISTANCE (120px).

Nothing distinguishes trackpad input from a discrete mouse wheel: Windows Chromium delivers mouse wheel deltas as DOM_DELTA_PIXEL, and the gestureScrollBegin/gestureScrollEnd brackets (forwarded in apps/desktop/src/window/DesktopWindow.ts:671) are emitted for mouse wheel scrolls too. The only escape hatch is canScrollHorizontally, which is why scrollers still work.

Possible directions: restrict swipe navigation to macOS (the momentum-tail heuristic targets macOS), detect discrete wheel ticks, or ship the opt-out setting requested in #28023.

Steps to reproduce

Windows desktop app 0.1.7, mouse with a horizontal tilt wheel.
Visit two threads so back history exists.
Hover over the chat (no horizontal scroller) and tilt the wheel left.
The back arrow appears and the app navigates to the previous thread.

Version

Desktop app 0.1.7 (local server reports 0.1.7). HistorySwipeNavigation.tsx is unchanged on main as of 2026-11-08.

Environment

Windows 10 Pro 19045 x64; desktop app with local server; Razer mouse with tilt mapped to Scroll left/right.

Evidence

shell

1	Source analysis at v0.1.7 (see Diagnosis). No logs: this is renderer input handling, which isn't traced.

#27430 (feature), #28091, #28475, #28160, #30160, #28023

Fix applied or workaround

None in-app. Remap or disable the tilt for T3 Code in the mouse driver.

Filed by

Triaged with Claude Code (Claude Opus 5.5) via t3 triage

Sshivam3d ago

[GPT-6.1 sol][Codex] on behalf of shivam.

Handed off to https://github.com/pingdotgg/t3code/pull/32963 after seeing Julius's fix.

Our independent check found the same pixel-mode wheel classification problem. A local Windows-only guard at 82eff91df2fa906b3ff48fb1b483a437fbbb3a77 makes the new Windows regression case pass; it fails on main ade473018d32003658b7d38693e083ee2e314bd8. Both focused swipe test files pass, 14 tests total. We also checked the real web client with two populated replay threads: a horizontal wheel over the conversation leaves the selected thread in place.

Native Windows behavior remains unverified from this run. The Windows VM host's T3 endpoint and SSH were unreachable. No competing PR was opened, and this thread is stopping its implementation work.