macOS(nightly): Phantom mouse drag when clicking an inactive split pane twice

[jwh926]

Issue Description

When using split panes, clicking on an inactive (unfocused) split pane and then
clicking again in the same pane triggers a phantom drag — text selection begins as if
the mouse button were held down, even though it was released between clicks.

2026-03-06.13.03.28.mov

First observed 4 hours ago on 1.3.0-main+3e220ab37. still reproduces on latest tip (1.3.0-main+055ed2858).

Expected Behavior

Clicking an inactive split once to focus it, then clicking again in the same pane
should place the cursor at the click position without initiating a drag/selection.

Actual Behavior

After the second click, Ghostty behaves as if the left mouse button is being held down:
moving the mouse selects text as if performing a click-and-drag, even though the mouse
button has been fully released. The phantom drag persists until the user clicks again to
"reset" the mouse state.

Reproduction Steps

1. Open Ghostty and create a split pane (e.g. ⌘+D or ⌘+Shift+D).
2. Click on the active (focused) split to ensure it has focus.
3. Click once on the inactive (unfocused) split — this focuses it.
4. Click once more in the now-focused split.
5. Move the mouse (without holding any button) — text selection/drag begins unexpectedly.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+055ed2858

Version
  - version: 1.3.0-main+055ed2858
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Tahoe 26.3

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

font-family = "Iosevka Term"
font-family = "Apple SD Gothic Neo"
font-size = 16
font-thicken = true
window-width = 160
window-height = 40
window-padding-x = 8
window-padding-y = 8
theme = Catppuccin Mocha
shell-integration-features = no-cursor
cursor-invert-fg-bg = true
cursor-style-blink = false
mouse-hide-while-typing = true
#background = #17161d
background-opacity = 0.90
background-blur = true
window-save-state = never
#unfocused-split-opacity = 1.0
split-divider-color = #36363f
keybind = shift+enter=text:\x1b\r

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[seruman]

I’m seeing the same behavior. I suspect it was introduced by c3febabd (likely macOS part 3ee8ef4f). I built and tested from the pre-merge parent 226d0b99, and the issue appears gone there.

[seruman]

Resetting the suppression state when focus is lost seems to resolve this but not sure if it's the correct way to do it; seruman@7b7e881

[jcollie]

I'm unable to reproduce on GTK, so this may be macOS only.

[amterp]

Seeing the same behavior on macOS with today's official 1.3.0 release (via brew install). It's more disruptive in practice than it might seem (at least for me) - the phantom selection triggers frequently enough when switching between splits to be distracting. Would love to see this prioritized if possible. Nice writeup @jwh926!

[sammcj]

I think in the mean time until this is resolved if you want to stay on the tip releases this build should be just before the bug was introduced

[amterp]

That seems to work, thanks for the suggestion @sammcj

[injust]

This happens with scrollback search as well:

Screen.Recording.mp4

[ardasevinc]

reproduced. in my case it also scrolls when i'm moving the mouse to another pane.

[mitchellh]

Thanks everyone, we'll get this fixed for 1.3.1. I think this is #11319

[kylematthews]

What's your expected timeline on this? It's driving me crazy, but I don't want to downgrade if it's a matter of days. Cheers, and thanks for the effort - love ghostty.

[ardasevinc]

What's your expected timeline on this? It's driving me crazy, but I don't want to downgrade if it's a matter of days. Cheers, and thanks for the effort - love ghostty.

it should be fixed on 1.3.1 which is already released

[kylematthews]

What's your expected timeline on this? It's driving me crazy, but I don't want to downgrade if it's a matter of days. Cheers, and thanks for the effort - love ghostty.

it should be fixed on 1.3.1 which is already released

well that was easy. thanks!