stablyai / stablyai/orca

[Bug]: Mouse wheel sends arrow keys to a normal-buffer CLI without mouse reporting, cycling its input history

Open
#8,563 6 comments 0 reactions 1 assignee Claimed by @OrcaWin View on GitHub
bug os:Windows pending_repro pending-user-response
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.