Mouse event reporting not implemented (clicks, motion, wheel)

[EugenEistrach]

Note: This issue was drafted by Claude (AI) based on a debugging session where we identified and fixed this in our application.

Problem

ghostty-web doesn't send mouse events to the PTY when applications enable mouse tracking. This affects TUI apps like opencode where:

• Scroll navigates input history instead of scrolling content
• Click-to-position doesn't work
• Mouse selection in apps like tmux/vim doesn't work

Missing Functionality

Event	xterm.js	ghostty-web
Wheel scroll	✅	❌ (converts to arrow keys)
Button press	✅	❌
Button release	✅	❌
Motion (drag)	✅	❌
Motion (any)	✅	❌

Root Cause

1. handleWheel only checks isAlternateScreen(), not mouse tracking mode
2. handleMouseDown/handleClick/handleMouseMove only handle UI features (links, scrollbar, selection) - they never send events to the PTY when mouse tracking is enabled

Native Ghostty properly checks mouse tracking mode and sends encoded mouse events (Surface.zig).

Proposed Fix

When hasMouseTracking() is true, intercept mouse events and send properly encoded sequences:

1. Check tracking mode (modes 9, 1000, 1002, 1003) to determine which events to report
2. Check encoding format (modes 1006 SGR, 1015 URXVT, or default X10)
3. Encode and send button/position data to PTY via dataEmitter

Button codes: left=0, middle=1, right=2, scroll-up=64, scroll-down=65

Encodings:

• X10: ESC [ M Cb Cx Cy (Cb/Cx/Cy = 32 + value)
• SGR: ESC [ < Pb ; Px ; Py M (press) or m (release)
• URXVT: ESC [ Pb ; Px ; Py M (Pb = 32 + code)

Workaround

We use attachCustomWheelEventHandler for scroll and added our own mousedown/mouseup/mousemove listeners that check tracking mode and send encoded events to the PTY.

Full implementation: https://gist.github.com/EugenEistrach/4adbb74d07e0108bac04d70051778f7f

[sreya]

Thanks for reporting, I'll look into fixing over the next few days!