Route mouse wheel scroll to the chat transcript instead of the prompt - #337
Merged
TheGreatAxios merged 4 commits intoAug 7, 2026
Conversation
The prompt textarea holds keyboard focus for the whole session and has its own scrollable buffer, so OpenTUI's wheel dispatch (hit-test, or fall back to the focused renderable when the hit misses) kept handing scroll events to the prompt instead of the transcript. Override the prompt's scroll handling to forward wheel/trackpad events to the transcript instead of scrolling its own buffer. Arrow-key history cycling in the prompt was already implemented and tested; verified it end to end via real key-event dispatch.
Calling the prompt's overridden onMouseEvent directly skipped the renderer's SGR-mouse parse and hit-test, so the test proved the forwarding function works without proving the renderer ever calls it on a genuine wheel scroll. Driving the same bytes through the mock mouse at the prompt's actual screen position closes that gap.
Wheel/trackpad scroll only reaches OpenTUI when the terminal is told to report it; otherwise the terminal's own alternate-scroll mode resends it as arrow keys, which the prompt reads as history navigation. Flipping the default lets routePromptWheelToTranscript run for real scroll instead of only after Alt+M. Trade accepted: this suppresses the terminal's native drag-select in the main shell, which a separate ticket recorded wanting the opposite default. Alt+M still hands the mouse back for drag-select and copy. enableMouseMovement stays off; only clicks and wheel need reporting.
TheGreatAxios
force-pushed
the
cl-5561-mouse-scroll-should-move-chat-not-the-prompt-arrows-cycle
branch
from
August 7, 2026 05:49
7ea2e4d to
c2f8101
Compare
These four spots described mouse reporting as off by default, matching the main shell's old behavior. The satellite pickers still keep reporting off on purpose, but the main shell now defaults it on, so the comments read backwards. Reword them to state each surface's actual behavior instead of claiming they match, and update the readiness doc to describe the decision as settled with current line references.
TheGreatAxios
deleted the
cl-5561-mouse-scroll-should-move-chat-not-the-prompt-arrows-cycle
branch
August 7, 2026 06:35
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
useMouse: true), so real wheel/trackpad scroll reaches OpenTUI instead of the terminal's alternate-scroll mode resending it as arrow keys that the prompt read as history navigationVerification
list-modal.tsandprovider-setup.tsare untouched and keep mouse reporting off, so their pickers keep native drag-select.useMouse: true, enableMouseMovement: false: the emitted DEC private modes are1000,1002,1006(plus unrelated terminal modes1049,2004,2026,2027,2031,25) —1003(any-motion tracking) is confirmed absent.1002(button-event tracking, which reports drags) is present, so a plain modifier-free drag is not recoverable by narrowing further; this was not re-tested since CL-5540 already falsified shift+drag empirically under the same1000-suppresses-selection condition.bun test): typed "hello-typed" into the live prompt, then sent 6 genuine SGR wheel-up sequences (\x1b[<64;col;rowM, the exact bytes the app's own emitted1000/1006modes request) at the prompt's on-screen row. The prompt content and cursor were unaffected — no scrolling, no history cycling, no corruption.h.mockMouse.scrollthrough the renderer's SGR parse and hit-test, not a direct method call) against seeded transcript rows and confirms the transcript moves and pins while the prompt's own buffer never scrolls; verified it fails without the fix and passes with it.bun run typecheck,bun run build, andbun test(4368 tests) all pass. A handful of unrelated tests (async markdown-highlight timing, transcript bottom-anchoring under load) flake intermittently across repeated full-suite runs but pass individually; confirmed pre-existing and unrelated to mouse/keyboard input handling.Closes CL-5561