#2
Issues/m-i-z-u-k-i/rexnux/#2

Mouse clicks do not reach terminal programs that enable mouse reporting

Openm-i-z-u-k-iOwneropened 2d ago

Summary

Clicking inside a terminal pane does not reach programs that use the mouse. TUIs and full-screen apps that enable mouse reporting (htop/btop, lazygit, opencode's UI, vim/neovim with mouse=a, etc.) do not react to clicks, drags or wheel events; the click appears to be taken by the client instead.

Expected: a click inside a pane is delivered to the program as a mouse report when it has enabled one of the mouse modes (1000/1002/1003, or 1006/SGR for coordinates), exactly as it is in Rex and in other Ghostty-based terminals.

Actual: the program never sees the press. Clicking still focuses the pane, so the client is receiving the event.

Suspects in this client

  • internal/ui/workspace.go attaches OnClick to the terminal element (tv.OnClick(...) calling focusPane) and to the pane card. That may consume the pointer press, or make the element's own input handling see it first.
  • The pane card also handles clicks for focus and the workspace may rebuild on the press, so the release can land on a different element than the press.
  • focusPane calls session.focus_block on every click; worth checking whether that refresh interrupts the terminal's mouse state.
  • Mouse coordinates are in window space; worth checking they reach the plugin in the terminal's own coordinate space given the panes are absolutely positioned inside a clipped card.

To reproduce

  1. Run a TUI that takes the mouse, e.g. btop or lazygit, in a pane.
  2. Click a row or a button on screen.
  3. Observe: nothing happens in the program; the pane only takes focus.

Environment

  • rexnux 5e14ed4
  • MyGo v0.7.4, terminal plugin (libghostty-vt)
  • Linux/Wayland, Hyprland
  • Rex server 0.1.0-preview.12, API revision 8

Activity

2
m-i-z-u-k-i added bug2d ago
m-i-z-u-k-iOwner1d ago

Follow-up from #6 (drag-and-drop tiling).

With pane headers hidden, each pane now has a 12 px invisible strip along its top edge that starts a pane drag. Today that strip takes pointer events before the terminal sees them, which is harmless while mouse reporting is broken, but once this issue is fixed it must not swallow mouse reports or text selection in that band.

When fixing #2, please make the strip coexist with the terminal: for example, only claim the press once the pointer actually moves into a drag (so a click still reaches the program), or shrink/disable the strip while a terminal has mouse reporting enabled. The same precedence check should apply to the pane card's focus click.