Let a trackpad scroll the transcript - #8
Merged
Merged
Conversation
Two independent paths dropped precision scrolling, and a laptop hits both. The wheel path rounded each event to whole lines and threw the remainder away. A mouse notch is several lines, so it survived rounding; a precision touchpad reports a few pixels per event, every one of which rounds to zero, so the transcript never moved no matter how long you scrolled. Accumulate the pixels and carry the sub-line remainder, the way the pan-zoom path already did. The pan-zoom path — what a trackpad two-finger scroll actually delivers on macOS and on Windows precision touchpads — returned early whenever the program had mouse reporting on. That is not what other terminals do, and mouse reporting is not an edge case: a full-screen agent holds the mouse for its entire run, so the one input a laptop has was dead for the whole session. Forward it as one wheel step per line crossed, which is the encoding SGR mouse actually has.
bharathm03
added a commit
to antgrid-ai/antgrid
that referenced
this pull request
Aug 27, 2026
Picks up antgrid-ai/dart_terminal#8. Two independent paths in the terminal view dropped precision scrolling, and a two-finger scroll hits both: the wheel path rounded each event to whole lines and discarded the remainder (a mouse notch survives that, a touchpad's few-pixel events all round to zero), and the pan-zoom path — what a trackpad actually delivers — returned early whenever the program had mouse reporting on, which a full-screen agent holds for its entire run.
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.
Two-finger scroll does nothing in the transcript on a laptop. Two independent paths drop precision scrolling, and a trackpad hits both — which is why nothing about the gesture worked, in either direction, at any speed.
The wheel path rounded the remainder away.
A mouse notch is worth several lines, so it survives rounding. A precision touchpad reports a few pixels per event — every one of them rounds to zero and is discarded, so the transcript never moves however long you scroll. The pan-zoom path already carried a sub-line remainder; the wheel now does the same.
The pan-zoom path was dropped outright whenever the program had the mouse.
PointerPanZoom*is what a two-finger scroll actually delivers (macOS always; Windows precision touchpads via DirectManipulation), and mouse reporting is not an edge case — a full-screen agent turns it on for its entire run. So the only scroll input a laptop has was dead for the whole session, and the comment justifying it ("matches iTerm2 / Terminal.app") describes behaviour neither of them has.SGR has no pan-zoom encoding, but it has wheel buttons, and one button-4/5 press per line crossed is what terminals that support both send. That is what the pan now forwards, reusing
_sendWheelStepso the encoding cannot drift from the real wheel's.Tests
Two new cases in
terminal_view_test.dart, both failing before this change:normalMouse+sgrMousereaches the program asBUTTON_FOURflutter testinpkgs/vte/ghostty_vte_flutter: 214 pass, 28 fail — the same 28 that fail onmasteron this machine (shell-launch and glyph-painting cases that need a POSIX shell / different font metrics).Not verified on hardware yet
The repros are synthetic pointer sequences, so they prove the code path, not the platform. Neither fix has been driven by a real trackpad — the machine reporting the bug is a laptop that isn't to hand.