Mouse input becomes stuck and selection scroll runs forever after switching focus

[mgkwill]

Issue Description

While using AI cli agents to do long running work I've experience mouse input freeze after text selection, where keyboard input still works. When this happens I can still Alt-Tab between windows and type in the terminal, but any selection or click (left or right) with the mouse is non-responsive. Closing the application and restarting fixes the issue for a time.

Succinct summary:
When you hold a mouse button in Ghostty (e.g. while selecting text) and switch to another window before releasing it, mouse input breaks when you return. Clicks are ignored, selection does not work.

Expected Behavior

Mouse state should reset cleanly when the window loses focus. Selection should stop, auto-scroll should stop, and mouse input should work normally when you return.

Actual Behavior

• Mouse clicks are ignored or cause unexpected selection behavior
• The auto-scroll timer continues running indefinitely in the background, flooding the I/O mailbox with tick events
• The terminal may become sluggish due to the runaway timer

Even without the auto-scroll scenario, simply holding any mouse button and alt-tabbing away can leave the mouse state stuck.

Reproduction Steps

1. Open Ghostty with some scrollback content
2. Start selecting text by clicking and dragging
3. While still holding the mouse button, drag past the top or bottom edge of the viewport (so auto-scroll kicks in)
4. Without releasing the mouse button, alt-tab or click to another window
5. Return to Ghostty

Ghostty Logs

No response

Ghostty Version

Ghostty 1.2.3 Stable (Installed through APT on Ubuntu 25.10)

OS Version Information

Ubuntu 25.10

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME Shell 49.0

Minimal Ghostty Configuration

Default configuration, no changes.

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.

[mgkwill]

I created this patch (with codex cli), built and have been running it for a few days. It appears to have fixed my issues. I was going to open a PR but read the contributing docs.

diff --git a/src/Surface.zig b/src/Surface.zig
--- a/src/Surface.zig
+++ b/src/Surface.zig
@@ -1159,7 +1159,13 @@ fn selectionScrollTick(self: *Surface) !void {

     // If we don't have a left mouse button down then we
     // don't do anything.
-    if (self.mouse.left_click_count == 0) return;
+    if (self.mouse.left_click_count == 0) {
+        self.queueIo(
+            .{ .selection_scroll = false },
+            .unlocked,
+        );
+        return;
+    }

@@ -3323,6 +3329,24 @@ pub fn focusCallback(self: *Surface, focused: bool) !void {
         }
     }

+    // Reset mouse state on focus loss
+    if (!focused) {
+        self.mouse.left_click_count = 0;
+        for (&self.mouse.click_state, 0..) |*state, i| {
+            if (state.* == .press) {
+                const button: input.MouseButton = @enumFromInt(i);
+                _ = self.mouseButtonCallback(.release, button, self.mouse.mods) catch |err| blk: {
+                    log.warn("error releasing mouse button on focus loss err={}", .{err});
+                    break :blk false;
+                };
+            }
+        }
+
+        if (self.selection_scroll_active) {
+            self.queueIo(.{ .selection_scroll = false }, .unlocked);
+        }
+    }
+
     // Schedule render which also drains our mailbox
     try self.queueRender();

diff --git a/src/apprt/gtk/class/surface.zig b/src/apprt/gtk/class/surface.zig
--- a/src/apprt/gtk/class/surface.zig
+++ b/src/apprt/gtk/class/surface.zig
@@ -2750,7 +2750,7 @@
-                log.warn("error in key callback err={}", .{err});
+                log.warn("error in mouse callback err={}", .{err});

@@ -2803,7 +2803,7 @@
-            log.warn("error in key callback err={}", .{err});
+            log.warn("error in mouse callback err={}", .{err});

[heyodog0]

I have the same issue as you, I am not familiar with submitting particular issues but I am just going to copy your patch fix.

I am running my stuff on a Mac mini and use a Logitech mouse, so that also may be causing issues somehow(?)

Will send updates if this actually works

[jcollie]

macOS users. Your problem is very likely not the same problem as this issue. It likely has already been fixed in #11276. Stop adding noise to this issue.

[ricardobeat]

@jcollie thank you! May I suggest to in the future leave the discussion open until the fix is released, as the Discussions search is only for open issues by default, and anyone coming in to report the issue in the meantime won't find it.

[jcollie]

If we don't close discussions/issues when the fixes are merged then they'll tend to stay open forever. Closing an issue when a fix has been merged is also an important step in maintainers being able to triage discussions. The fact that GitHub doesn't search closed discussions is moot - users should take it upon themselves to dig a bit deeper. There is also an issue and PR related to this.

[ricardobeat]

The pinned discussion rules instruct to look for existing posts before posting, but since all user feedback comes through discussions, it's not obvious to also search closed issues; especially for one so fresh. I don't have a suggestion to your particular workflow, maybe worth noting that in the guidelines to help reduce duplicates/noise (no need to answer this - it is just feedback).