feat(web): add a setting to disable history swipe navigation#28370

Approvability

Verdict: Approved at db2a71b

Macroscope's review found this PR approvable — Adds a desktop setting to disable swipe history navigation while keeping it enabled by default. The change is reversible and removes gesture listeners when disabled.

^{You can add or adjust custom eligibility rules. Learn more.}

Explain Change →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 934c7f8
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: c3ba3d87-e96e-48ad-b6b4-0c5df54f9868

External image Commits

Reviewing files that changed from the base of the PR and between db2a71b12f7d5a389f60aa0fc05f1ff56c72de54 and 18909a592b54869b13ed9300431dd9e607aff5dd.

External image Files selected for processing: 7

• apps/web/src/components/AppSidebarLayout.tsx
• apps/web/src/components/HistorySwipeNavigation.tsx
• apps/web/src/components/settings/SettingsPanels.tsx
• apps/web/src/components/settings/settingsSearch.test.ts
• apps/web/src/components/settings/settingsSearch.ts
• packages/contracts/src/settings.test.ts
• packages/contracts/src/settings.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Takeover update

merged current main into the branch at 18909a592b (merge commit, no rebase). one conflict in AppSidebarLayout.tsx: main added a showSidebar prop, the pr gates HistorySwipeNavigation on the setting. both kept. no other source changes; no required changes or actionable bot findings.

• blacksmith: vp run check:changed passed (format, lint, knip, typecheck of 37 packages, 7 test files, react compiler). AppSidebarLayout.browser.test.tsx, settingsSearch.test.ts and contracts settings.test.ts pass.
• the electron client was not re-driven after the merge. the evidence below is from db2a71b.

Earlier verification (gpt-6.1-sol)

Verified in a real dev environment

verified as-is at db2a71b12f7d5a389f60aa0fc05f1ff56c72de54 on this linux vm. no source changes.

• reproduced on github/main at 8b74a69019e3 first: horizontal wheel input navigates between threads, with no setting to disable it.
• used real dev servers, chrome through repository playwright, and the actual electron 44 desktop client built from each revision. created a real git project and two threads through the app. codex gpt-6.1-sol completed both main turns and another turn through the pr's web client. no mocks or seeded conversations.
• in desktop settings, the control defaults on. switching off blocks both directions and removes the indicator. re-enabling restores both directions without reload. disabling during a swipe removes its indicator. the disabled preference survives reload.
• keyboard and toolbar back/forward still work while swipes are disabled. settings search for "horizontal wheel", per-setting reset, and restore device defaults work. chrome correctly hides the desktop-only control.
• blacksmith: desktop build and vp run check:changed 15fe2832727893cbdd2214383f9f971474849695 passed, including 35-package typechecking, 64 tests across six files, and four react compiler cases. all 31 reported ci checks pass.

after disabling, the real-client checks reported:

before, main settings with matching project data and viewport:

main general settings without a swipe control

pr, enabled:

pr general settings with swipe navigation enabled

pr, disabled:

pr general settings with swipe navigation disabled

main: horizontal wheel input moves beta to alpha and back.

main desktop wheel navigation between real codex threads

pr: disabled swipes leave the thread unchanged; keyboard and toolbar navigation still work; enabling restores swipe navigation. these animations contain the full recordings. the original mp4s were inspected and played through in t3, including seeking.

pr disabling swipes, preserving other navigation, and re-enabling

Not verified

macos hardware input from a physical trackpad or logitech mx master, mouse thumb buttons, windows desktop, native ios/android, and relay/tunnel connections were not exercised on this linux vm. the wheel checks used trusted chromium input through the real electron renderer and gesture ipc, so they do not prove macos hardware event provenance.

I'm a huge +1 on this PR. I use an Apple Magic Trackpad, and I couldn't understand what was happening: while I was scrolling, my threads kept suddenly switching from one to another.

need this urgently

I keep running into issues using shift+scroll to horizontally scroll diffs but end up over scrolling and moving forward/back in navigation history. It's incredibly obnoxious. Would this proposed setting fix that since over scrolls are considered swipes?

+1. Same on macOS desktop with an MX Master 3S: horizontally scrolling a wide Markdown table with the thumb wheel, once the table hits its edge the swipe indicator appears and the app jumps to another thread. It is easy to miss and confusing. It also happens with the trackpad in the same situation, so a setting to turn the gesture off would help both cases.

Same issue on Zorin OS 18.1 (Ubuntu-based), Wayland, T3 Code 0.1.7, with an MX Master 4. Horizontal thumb-wheel scrolling switches threads. Would appreciate this toggle.

🤖 Update on behalf of Mateusz (PR author): how this PR relates to the swipe fixes opened since.

• #32963 (fixes #32955) makes two-finger swipe macOS-only, because on Windows and Linux Electron cannot tell a tilt wheel from a trackpad. Touchpad users there lose the gesture; macOS keeps it unchanged.
• macOS, which #32963 leaves unchanged, has the same blind spot: Electron gives no trackpad-vs-wheel provenance there either. A horizontal mouse wheel (the MX Master thumb wheel this PR was opened for, on macOS) still drives the gesture.
• #28475 stops scrolls at the edge of a horizontal scroller from navigating. It does not cover a horizontal wheel over areas that do not scroll sideways, which is the case here.

This switch is the per-user escape hatch the platform check cannot provide: mouse users on macOS can turn the gesture off without taking it away from trackpad users. If #32963 lands first, I'll rebase and show the switch only where the gesture exists. #31728 proposes the same switch; happy to close this one in favour of whichever you prefer.

No code change in this update.

macos hardware input from a physical trackpad or logitech mx master, mouse thumb buttons, windows desktop, native ios/android, and relay/tunnel connections were not exercised on this linux vm.

Adding the hardware side that the verification above could not cover (it ran on a Linux VM with synthetic wheel input).

I have used this change daily since 31 October in desktop builds on a MacBook Pro on macOS 26.6 with a Logitech MX Master and the built-in trackpad:

• Switch on (the default): a two-finger trackpad swipe goes back and forward as on main. The MX Master's thumb wheel triggers the same navigation, which is the misfire that made me open this PR.
• Switch off: neither the thumb wheel nor a trackpad swipe changes the thread. Keyboard and toolbar back/forward still work.
• The choice has survived every restart and app update since.

On #32963: it leaves macOS unchanged, so this case stays open there. If it lands first, I'll rebase this PR and show the switch only where the gesture exists.

Tested locally at 18909a592b on macOS, with a trackpad and an MX Master 3.

• Switch on: two-finger swipes and the thumb wheel navigate as before.
• Switch off: neither trackpad swipes nor the MX Master thumb wheel navigate anymore.
• ⌘[ / ⌘] and the back/forward buttons still work with it off.
• Turning it back on takes effect right away, no reload needed.

+1 to getting this merged -- accidental navigation happens to me multiple time per day.

@maria-rcks @juliusmarminge thanks for keeping this one and closing my duplicate (#34481). +1 to merge: it is clean against main, and kelchm and chomamateusz have confirmed it on macOS with a trackpad and an MX Master.

Two small refinements from #34481 that Julius mentioned. Neither needs to block this PR; I can open them as a follow-up after it merges, or you can take them here:

• Since #32963 the gesture runs only on macOS, so on Windows and Linux desktop the switch does nothing. Show the row only when isElectron && isMacPlatform(navigator.platform), and mark its search item macOnly: true.
• One line in docs/user/keybindings.md, after navigation.back / navigation.forward: "In the desktop app on macOS, a two-finger trackpad swipe does the same. Turn it off in Settings."