macOS: clicking unfocused window should not encode VT mouse event

[mitchellh]

See #2593 for detailed discussion including comparisons to other terminals.

Steps to reproduce:

1. Open Ghostty and launch htop (so we have click targets)
2. Focus another macOS application while having the Ghostty window visible in the background
3. Click a process in Ghostty

What you'll see is that the row is highlighted. Ghostty comes to focus and encodes the pty event so htop highlights the row.

What should happen: If the surface is unfocused or the app is unfocused, a click should bring it (the surface and window) to focus but not generate a pty event.

[mitchellh]

cc @emilazy

[emilazy]

Happy to try implementing this! Do you have any pointers to where I should start looking for the handling of this behaviour? I’m guessing somewhere in the Swift code?

[mitchellh]

Sure! I believe the fix will be entirely Swift. I don't think any Zig will be touched at all.

The direction I was heading into was utilizing acceptsFirstMouse as a signal of when this behavior should happen (the behavior to not encode a mouse event). I added some logging there and in all the mouse events and noticed that:

1. acceptsFirstMouse always happens before mouseDown
2. acceptsFirstMouse never happens before any other mouse event (tried right, middle, scrolling)
3. acceptsFirstMouse happens anytime the window is not focused (i.e. it happens even when the app is focused)

Given this, my thinking was: set a flag in acceptsFirstMouse, when mouseDown sees it, it does NOT call the ghostty mouse event callback, reset the flag.

I don't know if that's robust enough or the right approach, but that's where I was looking...

[emilazy]

Coming back to this after a while :)

I take it the idea is that we can’t just refuse acceptsFirstMouse because it would break the desired behaviour of still focusing a split on click, so we have to sorta hack around it by using the notification as an indicator of what the next mouse event is going to be?

One complication is that we need command+click to send an event through without raising, as is standard macOS behaviour. Not sure how acceptsFirstMouse will behave with that.