GNU bug report logs - #76629
NS click events don't select right window

Previous Next

Full log

View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>, 76629 <at> debbugs.gnu.org
Subject: bug#76629: NS click events don't select right window
Date: Mon, 03 Mar 2025 11:19:16 -0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
>
>> This change appeared on master in 3545988740.
>>
>> Is there really a consensus for this? Click-through does not appear
>> how (MacOS) applications work in general. While it seems useful for
>> switching between unobscured Emacs windows, it's a bit surprising
>> when clicking on a partially obscured Emacs in order to raise and
>> activate it.
>>
>> Is there a way to make the behaviour more conditional in this
>> respect? Or, at least, configurable.
>
> IIUC, this is how Emacs used to behave on macOS, so I originally treated
> this as just a bug fix.
>
> That said, I have no objection to making it optional, of course.
>
> I also don't have an opinion on what should be the default because:
> - the historical behavior of Emacs, and similarity to other platforms,
>   seem to speak in favor of having this on by default
> - being consistent with macOS seems to speak in favor of having it off

The situation seems a bit more nuanced than a choice of "on" or "off".
I think the concept is that you're supposed to enable click-through for
"utility" items (like toolbar buttons) and for document *selection*, but
require a second click for interaction with documents.

You can see this behavior in Chrome.  Start it up, go to a web page,
then give some other app focus.  When Chrome is no longer focused, click
its page reload button.  The page will reload immediately.  Now switch
focus again, and this time click a link on the page.  The click just
focuses and raises the Chrome window.  You have to click a second time
to follow the link.

It looks like Apple's put a lot of thought into the click-through model.
If we're going to follow the same pattern, we should use click-through
for toolbar buttons, mode-line stuff, and so on, but not for window
interaction.  A non-focused click on an Emacs window should *select* the
window but not execute any special commands in that window,
e.g. following links, expanding headers, and so on.  It probably
shouldn't move point either.

Others have been tripped up by this too:
https://github.com/microsoft/vscode/issues/24634

We might be able to implement this model by letting the first click go
through only if it resolves to some command that has a new
ns-first-click-capable property or interactive spec or something.

That's a lot of work, so I'd rather just have an on/off toggle right now
with a todo.  I'd prefer to default the setting to on, since Emacs is
more convenient to use this way.

> Please let your voices be heard, if you have a reasoned opinion here.
>
> Daniel, could you perhaps look into adding a defcustom for this?

Sure.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.