Linux/GTK: Shift+drag selection works once, then stops (stuck mouse state with tmux + mouse-reporting TUI)

[creatiVision]

Environment

• Ghostty 1.3.1 (stable), Linux, X11 session, GTK runtime
• tmux with set -g mouse on
• TUI app running in the pane: kimi-code (Claude-Code-style CLI, enables mouse reporting)
• Relevant Ghostty config: mouse-shift-capture = never, copy-on-select = clipboard

Description

With a mouse-reporting TUI app running inside tmux, the first Shift+drag text
selection works. After that, Shift+drag stops selecting entirely — the selection
cannot be reactivated. Plain drags (captured by tmux) keep working.

Expected Behavior

Every Shift+drag should start a fresh native text selection.

Actual Behavior

• First Shift+drag after terminal activation: works (selects, copies on release
  via copy-on-select).
• All subsequent Shift+drags: no selection starts. The mouse/selection state
  appears stuck.

Steps to Reproduce

1. Start tmux (mouse mode on) in Ghostty on Linux.
2. Run a TUI app that enables mouse reporting (e.g. kimi-code) in the pane.
3. Shift+drag to select text — works.
4. Shift+drag again — nothing is selected.

Additional Context

• Related macOS report with the same class of bug (stale mouse anchor / stuck
  mouse state with AI CLI TUIs): Discussion #10974 —
  "Mouse text selection becomes erratic in all panes when Claude Code CLI is
  running in one pane". This report is the Linux/GTK variant.
• Setting mouse-shift-capture = never was required to make the first Shift+drag
  work at all (with true, Shift is forwarded to the app via the mouse protocol
  and no native selection happens).
• On macOS, switching focus away and back resets the state (per Mouse text selection becomes erratic in all panes when Claude Code CLI is running in one pane #10974). Unknown
  whether this works on Linux/GTK.

Ghostty Version Info

Ghostty 1.3.1
Version: 1.3.1 (stable)
OS: Linux (X11)
Runtime: GTK

[creatiVision]

Update: this was not a Ghostty bug — config error on my side.

After further investigation, the root cause was my local Ghostty configuration, not a Ghostty defect:

• Environment: Ghostty 1.3.1, Linux (X11, GTK runtime), tmux with mouse mode, and a mouse-reporting TUI (kimi-code) in the pane.
• The "selection works once, then stops" symptom was caused by my scrollbar = system setting. The GTK scrollbar widget was capturing mouse events and interfering with native text selection.
• Changing to scrollbar = never fully resolves the issue — Shift+drag selection and copy-on-select now work reliably.

I apologize for the false report. Per the CONTRIBUTING guide, this falls into the "environmental problems / configuration errors" category. Feel free to close this discussion as "not a Ghostty bug".

Note: the related macOS report (#10974) may still describe a genuine mouse-state issue — my report was the Linux/GTK variant, but on Linux the cause turned out to be the scrollbar widget, not the mouse-state code.

[creatiVision]

Follow-up: the missing scrollbar is a real remaining issue.

The scrollbar = never workaround fixes selection, but it removes the scrollbar
entirely. This exposes a genuine functional gap on Linux/GTK:

• With scrollbar = system, the GTK scrollbar widget captures mouse events and
  breaks native text selection (the original symptom).
• With scrollbar = never, selection works, but there is no scrollbar at all.
• There is no third option — Ghostty currently offers only system and never
  for the scrollbar setting. There is no built-in, Ghostity-rendered scrollbar.

So on Linux/GTK, users must choose between having a scrollbar and having
working mouse selection. That is not a configuration error — it is a conflict
between two standard features that should coexist.

Likely mechanism: when a mouse-down lands on the GTK scrollbar widget but the
mouse-up is delivered to the terminal surface (or vice versa), the terminal's
mouse-button state desyncs and it believes the button is still held. The next
selection then continues from a stale anchor — which is exactly the "works once,
then stops" symptom reported here.

Request: either

1. Fix the system-scrollbar integration so the GTK widget does not capture mouse
   events meant for the terminal surface (e.g., only capture events when the
   pointer is over the scrollbar gutter, never during an active selection), or
2. Add a native Ghostity-rendered scrollbar (drawn in the terminal grid, like the
   macOS overlay scrollbar) as a third scrollbar value.

Until then, scrollbar = never is the only reliable workaround for Linux/GTK
users who need mouse selection.

[jcollie]

Can you replicate this with a source built from main? 1.3.1 is pretty old as far as Ghostty releases go, there have so many changes it's not really worth debugging an issue unless it can be reproduced on main.

[creatiVision]

Note: tmux is not a factor in this issue.

For isolation purposes — this reproduces independently of tmux:

• The scrollbar is a Ghostity/GTK widget drawn on the right edge of the terminal
  window. It captures mouse events at the window level, before they reach the
  terminal surface, and therefore before they could reach tmux.
• With mouse-shift-capture = never, Shift+drag selection is handled natively by
  Ghostity and is not forwarded to tmux at all — so tmux is not in the code path
  for the broken selection.
• The "works once, then stops" symptom is a Ghostity-level mouse-state desync:
  a mouse-down captured by the scrollbar widget (with the mouse-up delivered to
  the terminal, or vice versa) leaves the native selection thinking the button
  is still held.
• The fix (scrollbar = never) only removes the Ghostity/GTK scrollbar and
  changes nothing about tmux — confirming the bug is in the Ghostity/GTK layer.

To reproduce without tmux: open a fresh Ghostity window running plain zsh, keep
scrollbar = system, and attempt Shift+drag selection — it breaks the same way.

[trag1c]

!denounce meatproxying