[Bug]: Mouse wheel sends arrow keys to a normal-buffer CLI without mouse reporting, cycling its input history
- Dominant language
- TypeScript
- Stars
- 69.7k
- Forks
- 4.5k
- Avg merge
- 15h 28m
- Merged PRs (30d)
- 471
Description
### Operating system
Windows
### Orca version
v1.4.137 (Windows 11, win32 10.0.26200)
### Details
Short summary:
Scrolling the mouse wheel over a pane running an inline (non-alt-screen) CLI TUI cycles the app's prompt/input history instead of scrolling the terminal scrollback — wheel-up behaves like repeated Up-arrow presses delivered to the PTY.
What happened?
The hosted app (GJC, a CLI coding agent):
- never enables mouse reporting (no `CSI ?1000h` / `?1006h`; it even writes `?1000l`/`?1006l` on exit),
- never enters the alternate screen (no `CSI ?1049h`) — it renders inline on the normal buffer,
- only pushes the kitty keyboard protocol (`CSI > 7 u`).
Per xterm.js `MouseService._handlePassiveWheel`, wheel-to-arrow synthesis should only fire when `!buffer.hasScrollback` (i.e. the alt buffer), and Orca's scrollback policy floor is 1,000 rows (default 5,000), so the normal buffer always has scrollback. Orca's own wheel multiplier (`pane-terminal-mouse-wheel.ts`) is also gated on the `enable-mouse-events` class, which never applies here. So no code path should be synthesizing arrows for this app, yet arrows arrive: the app maps Up/Down on an empty editor to prompt-history navigation, which matches the observed history cycling exactly.
Possible suspects: the TUI wheel-report changes merged in #7179 (synthetic wheel report replay/burst logic), or the patched-viewport work in #7450.
How can we reproduce it?
1. Run any inline (non-alt-screen) TUI that maps Up/Down to input history and does not enable mouse reporting — e.g. a CLI agent REPL.
2. Type a few prompts so history exists, leave the input empty.
3. Scroll the wheel up over the pane.
4. Expected: terminal scrollback scrolls. Actual: the app's input history cycles (arrow keys are delivered to the PTY).
Anything else that might help:
Shift+wheel and dragging the scrollbar still scroll the real scrollback, so the viewport itself is fine; only the plain wheel path misroutes.
Contributor guide
Assessment
This issue has not been assessed yet.