Clicking into an inactive window on macOS does more than simply raise it

[emilazy]

On macOS, clicks in inactive windows conventionally raise the window without performing any further action. This UI principle (as with all macOS UI principles…) has been eroded over the years, but still holds strong in Terminal.app. Ghostty violates it, which is surprising when switching between terminal applications with mouse support.

I’d be happy to try making a PR for this, although I’m less sure where to start than with the GPU selection. Not sure what the GNOME convention is and whether it should be matched there.

[mitchellh]

Just converting to a discussion until we narrow this down further, then I'll convert it back once we have an actionable conclusion.

I believe this was done on purpose but can't remember why. Here is the code that does it with a comment:

        override func acceptsFirstMouse(for event: NSEvent?) -> Bool {
            // "Override this method in a subclass to allow instances to respond to
            // click-through. This allows the user to click on a view in an inactive
            // window, activating the view with one click, instead of clicking first
            // to make the window active and then clicking the view."
            return true
        }

I'm trying to find the history of why we do this.

[mitchellh]

Okay, I think this is so that mouse clicks onto a split focus that split. Terminal.app and iTerm2.app behave differently here and we're trying to get to iTerms behavior in this way. The steps:

1. Create a split (horizontal/vertical doesn't matter)
2. Focus another app in the foreground while still being able to see the terminal in the background
3. Click the unfocused split of the terminal application.

For Terminal.app, it focuses the app but does NOT focus the split. The previously focused split remains focused.
For iTerm2, it focuses the app and SWITCHES split focus. However, it does not send the click event down into the pty.
For Ghostty, we focus the app, switch focus, but ALSO send the click event down to the pty.

I think it's reasonable to say that the click event should not be sent to the pty, but we should change split focus. This was an issue that I accepted some time ago. I'm not exactly sure how to fix this yet but thoughts?

[mitchellh]

Some more details:

Terminal.app NEVER sends the pty event when the window/view is not focused.

iTerm2.app sometimes sends the pty event. If you unfocus iTerm2 and then click on an iTerm2 window that was previously focused, it will send the pty event. It only doesn't send the pty event if you click into a previous unfocused split.

This behavior of iTerm2 seems wrong to me. I think in Ghostty if we change the behavior, it should be that the initial click into an unfocused surface (regardless of if the app/window was previously focused or not) should not encode the pty event.

[emilazy]

(Sorry for not opening a discussion to begin with! I figured this was just an oversight, not something that had come up already.)

I think that personally my macOS intuition is that the split focus would not change, but I can understanding differing opinions on that. I would not be nearly as surprised by split focus changing as by PTY events being sent.

[mitchellh]

I would not be nearly as surprised by split focus changing as by PTY events being sent.

I agree, this is what I'm leaning towards.

I'm pretty happy with the split focus changing, and I think that's pretty harmless (just something to get used to). Given the prior art to some extent with iTerm2 I think that makes it extra okay too.

EDIT: Opened issue #2595 for this.

[mitchellh]

On macOS, clicks in inactive windows conventionally raise the window without performing any further action.

In further researching this, I want to clarify that this doesn't seem to be unconditionally true. It seems to depend on the UI element. For example, NSScrollBars immediately respond to an unfocused click. So, it seems to depend based on what the behavior of the UI element is.

I note this because it does give us some wiggle room on how we interpret our clicks in our views. It doesn't seem to be an unconditional macOS truth (I haven't referenced the HIG yet).

[emilazy]

Right. I think that this used to be more consistent in the past. However, the subset of the rule I believe to be consistent among the first‐class first‐party apps is that events never go through to content on raise. For instance, clicking into inactive web content in Safari will never submit a form or anything like that. It’s convenient because it gives you a large click target to raise things with without worrying about exactly what you’re going to hit. I see terminal content as analogous to web content, so I believe that click events should never be sent to programs from a raise. (Mouse position events arguably should be, though; in Safari, that only happens on raise, not when the window is inactive, and you get the standard cursor even when hovering over an inactive link, to reflect that clicks won’t actually go through.)

[ofaizulin]

Came across this discussion while looking for an option on how to actually disable this behavior.

While it may be conventional, it also makes user to do extra mile, what makes app feel (subjectively) slow, especially when coming from windows or linux (gnome).

Just a brief test summary on "acceptsFirstInput", referencing a few apps open currently for me:

• Ghostty/Safari/Chrome: clicking on content swallows click, but it switches tabs (really, macOS?!...)
• Telegram: doesn't require extra click
• Whatsapp: requires extra click
• VS Code: doesn't require extra click
• Jetbrains *: doesn't require extra click
• Steam: doesn't require extra click
• MS Teams: requires extra click
• Outlook: requires extra click

What i'm trying to say, it's not all black and white, and, frankly speaking, it's a bit disappointing to have such behavior change at least without option to fall back :(

P.S. Just don't remove quit-after-last-window-closed please :)