Repository navigation
Codex and other page-key CLIs: a mouse wheel does nothing for the first 4 to 6 notches #697
Description
What happens
On a Codex session (and any CLI paged with PageUp and PageDown), a mouse wheel does nothing for the first few notches. Measured from rest, a fresh page, 100 px notches 450 ms apart over a hollow Codex pane of 38 rows:
| Wheel | First screen movement | Notches that did nothing |
|---|---|---|
| Chrome style, 4 rows a notch | notch 5 | 4 |
| Firefox style, 3 rows a notch | notch 7 | 6 |
So a short scroll of one to four notches looks like the wheel is dead, while PageUp and PageDown (sent by the keyboard) respond at once.
Why
When the CLI does not track the mouse, _maybePageCliTranscript turns the wheel into whole-page keys. pageKeysForGesture pages only after half a screen of travel (19 rows on 38 rows), except for a trackpad-sized opening event (under 2 rows), which pre-pays its page and owes the travel back. A mouse notch is 3 to 4 rows, so it only accumulates. The comment on PAGE_KEY_IMMEDIATE_MAX_ROWS records the reason: paging at once on a notch made slow notches, each its own gesture past the gap, page a full screen apiece.
Expected
The first notch moves the transcript, and a mouse pages at the same rate it does now.
Fix
Fix: #699. The related problem of the wheel moving a Codex menu's selection is #696 (fix: #698). The change: the first notch of a gesture pre-pays its page as a trackpad flick does, and the notches after it repay it. A notch's debt lasts 3 s, so slow notches still do not page a screen each. The page count over a gesture is unchanged, and the first page arrives with the first notch.
Activity