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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76629 in the body.
You can then email your comments to 76629 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: "Eshel Yaron via Bug reports for GNU Emacs,  the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Subject: NS click events don't select right window
Date: Thu, 27 Feb 2025 22:51:18 -0500

Say we have a NS Emacs frame with two windows --- let's say L and R.
We select L, then switch to another app on the OS.  Then we click on the
Emacs window in the area owned by R.  I observe Emacs being focused but
the selected window being L!  If I click in exactly the same spot again,
*then* R is selected.  But I need two clicks where one should suffice.

Message #8 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 76629 <at> debbugs.gnu.org
Subject: Re: bug#76629: NS click events don't select right window
Date: Sun, 2 Mar 2025 16:41:59 -0500

[Message part 1 (text/plain, inline)]

I use the NS builds, both as my production (now 30.1) and from master, and
I do not see this behavior.  Do you have implied window selection features
enabled like focus-follows-mouse or mouse-autoselect-window?  Do you use
any mac applications or helpers that might be interfering?

On Thu, Feb 27, 2025 at 10:52 PM Daniel Colascione <dancol <at> dancol.org>
wrote:

> Say we have a NS Emacs frame with two windows --- let's say L and R.
> We select L, then switch to another app on the OS.  Then we click on the
> Emacs window in the area owned by R.  I observe Emacs being focused but
> the selected window being L!  If I click in exactly the same spot again,
> *then* R is selected.  But I need two clicks where one should suffice.
>
>
>
>

[Message part 2 (text/html, inline)]

Message #11 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76629 <at> debbugs.gnu.org
Subject: Re: bug#76629: NS click events don't select right window
Date: Sun, 02 Mar 2025 17:06:06 -0500

On March 2, 2025 4:41:59 PM EST, Ship Mints <shipmints <at> gmail.com> wrote:
>I use the NS builds, both as my production (now 30.1) and from master, and
>I do not see this behavior.  Do you have implied window selection features
>enabled like focus-follows-mouse or mouse-autoselect-window?  Do you use
>any mac applications or helpers that might be interfering?
>

Don't know why you're not seeing it. Apparently macOS is supposed to behave this way unless you override <https://developer.apple.com/documentation/appkit/nsview/acceptsfirstmouse(for:)>, which I have made Emacs do

Message #14 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 76629 <at> debbugs.gnu.org
Subject: Re: bug#76629: NS click events don't select right window
Date: Sun, 2 Mar 2025 17:22:34 -0500

[Message part 1 (text/plain, inline)]

I'm on 12.7.6, perhaps this is associated with behavioral changes in later
macOS releases.  Do you have an example of another application you switch
to when you see this behavior?  I switch to Chrome or another Emacs session
or Terminal.app and back and I don't see the issue.  The window I last
selected remains selected and if I click in any other window, that one is
correctly selected.  I tried again both with my configuration and on master
with -Q and it seems fine.

On Sun, Mar 2, 2025 at 5:06 PM Daniel Colascione <dancol <at> dancol.org> wrote:

>
>
> On March 2, 2025 4:41:59 PM EST, Ship Mints <shipmints <at> gmail.com> wrote:
> >I use the NS builds, both as my production (now 30.1) and from master, and
> >I do not see this behavior.  Do you have implied window selection features
> >enabled like focus-follows-mouse or mouse-autoselect-window?  Do you use
> >any mac applications or helpers that might be interfering?
> >
>
> Don't know why you're not seeing it. Apparently macOS is supposed to
> behave this way unless you override <
> https://developer.apple.com/documentation/appkit/nsview/acceptsfirstmouse(for:)>,
> which I have made Emacs do
>

[Message part 2 (text/html, inline)]

Message #17 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 76629 <at> debbugs.gnu.org
Subject: Re: bug#76629: NS click events don't select right window
Date: Sun, 02 Mar 2025 18:05:42 -0500

Ship Mints <shipmints <at> gmail.com> writes:

Please don't top-post.

> I'm on 12.7.6, perhaps this is associated with behavioral changes in later
> macOS releases.  Do you have an example of another application you switch
> to when you see this behavior?  I switch to Chrome or another Emacs session
> or Terminal.app and back and I don't see the issue.  The window I last
> selected remains selected and if I click in any other window, that one is
> correctly selected.  I tried again both with my configuration and on master
> with -Q and it seems fine.

That's a pretty old version.  It's also after EOL, so you're risking
security problems by not upgrading.

As for the click change ---- who knows? Maybe Apple has
changed something. Emacs works fine on master now.

Message #22 received at 76629-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>, Ship Mints <shipmints <at> gmail.com>
Cc: 76629-done <at> debbugs.gnu.org
Subject: Re: bug#76629: NS click events don't select right window
Date: Sun, 2 Mar 2025 17:18:55 -0800

Version: 30.1

Daniel Colascione <dancol <at> dancol.org> writes:

> Ship Mints <shipmints <at> gmail.com> writes:
>
> Please don't top-post.
>
>> I'm on 12.7.6, perhaps this is associated with behavioral changes in later
>> macOS releases.  Do you have an example of another application you switch
>> to when you see this behavior?  I switch to Chrome or another Emacs session
>> or Terminal.app and back and I don't see the issue.  The window I last
>> selected remains selected and if I click in any other window, that one is
>> correctly selected.  I tried again both with my configuration and on master
>> with -Q and it seems fine.
>
> That's a pretty old version.  It's also after EOL, so you're risking
> security problems by not upgrading.
>
> As for the click change ---- who knows? Maybe Apple has
> changed something. Emacs works fine on master now.

Thanks, I can confirm that this is fixed by your commit
354598874061ab9ecb9362d7ac4233494b51252b.

I'm therefore closing this bug report.

Message #25 received at 76629-done <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Stefan Kangas <stefankangas <at> gmail.com>, Ship Mints <shipmints <at> gmail.com>
Cc: 76629-done <at> debbugs.gnu.org
Subject: Re: bug#76629: NS click events don't select right window
Date: Sun, 02 Mar 2025 20:24:33 -0500

On March 2, 2025 8:18:55 PM EST, Stefan Kangas <stefankangas <at> gmail.com> wrote:
>Version: 30.1
>
>Daniel Colascione <dancol <at> dancol.org> writes:
>
>> Ship Mints <shipmints <at> gmail.com> writes:
>>
>> Please don't top-post.
>>
>>> I'm on 12.7.6, perhaps this is associated with behavioral changes in later
>>> macOS releases.  Do you have an example of another application you switch
>>> to when you see this behavior?  I switch to Chrome or another Emacs session
>>> or Terminal.app and back and I don't see the issue.  The window I last
>>> selected remains selected and if I click in any other window, that one is
>>> correctly selected.  I tried again both with my configuration and on master
>>> with -Q and it seems fine.
>>
>> That's a pretty old version.  It's also after EOL, so you're risking
>> security problems by not upgrading.
>>
>> As for the click change ---- who knows? Maybe Apple has
>> changed something. Emacs works fine on master now.
>
>Thanks, I can confirm that this is fixed by your commit
>354598874061ab9ecb9362d7ac4233494b51252b.
>
>I'm therefore closing this bug report.

Thanks!

Message #28 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 76629 <at> debbugs.gnu.org
Subject: bug#76629: NS click events don't select right window
Date: Mon, 3 Mar 2025 11:03:57 +0100

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.

Message #31 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 76629 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#76629: NS click events don't select right window
Date: Mon, 3 Mar 2025 07:37:17 -0500

[Message part 1 (text/plain, inline)]

You and I are clearly using Emacs differently.  I'd like to observe this
behavior myself.  Can you describe what you're doing?  When you say
partially obscured Emacs, what do you mean?  Example, I almost always run
Emacs with maximized frames (not full screen).  I split a frame left and
right into two windows L and R as Daniel had.  I'll switch to Messages
which partially obscures Emacs with.  Then back.  I almost always do this
with the keyboard at least a hundred times per day.  I've tried the pointer
recently due to Daniel's prompting, but didn't see the issue.

-Stephane

On Mon, Mar 3, 2025 at 5:05 AM Mattias Engdegård <
mattias.engdegard <at> gmail.com> wrote:

> 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.
>
>
>
>
>

[Message part 2 (text/html, inline)]

Message #34 received at 76629 <at> debbugs.gnu.org (full text, mbox):

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

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

Please let your voices be heard, if you have a reasoned opinion here.

Daniel, could you perhaps look into adding a defcustom for this?

Message #37 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 76629 <at> debbugs.gnu.org,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#76629: NS click events don't select right window
Date: Mon, 3 Mar 2025 13:40:25 -0500

[Message part 1 (text/plain, inline)]

I can't reproduce the behavior, so it's hard for me to say.

On Mon, Mar 3, 2025 at 1:35 PM Stefan Kangas <stefankangas <at> gmail.com> wrote:

> 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
>
> Please let your voices be heard, if you have a reasoned opinion here.
>
> Daniel, could you perhaps look into adding a defcustom for this?
>
>
>
>

[Message part 2 (text/html, inline)]

Message #40 received at 76629 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.

Message #43 received at 76629 <at> debbugs.gnu.org (full text, mbox):

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

Daniel Colascione <dancol <at> dancol.org> writes:

> 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.

[...]

> 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.

Thanks for taking the time to look into this properly.

If no one will volunteer to implement the more involved version, I agree
that a defcustom is the best we can do for now.

>> 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.

Thanks!

Message #46 received at 76629 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#76629: NS click events don't select right window
Date: Mon, 03 Mar 2025 11:39:07 -0800

On March 3, 2025 11:33:00 AM PST, Stefan Kangas <stefankangas <at> gmail.com> wrote:
>Daniel Colascione <dancol <at> dancol.org> writes:
>
>> 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.
>
>[...]
>
>> 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.
>
>Thanks for taking the time to look into this properly.
>
>If no one will volunteer to implement the more involved version, I agree
>that a defcustom is the best we can do for now.

We can make a menu defoption with 'always and 'never choices for click through, then add an 'auto option later.

Message #49 received at 76629 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 76629 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76629: NS click events don't select right window
Date: Mon, 3 Mar 2025 14:44:52 -0500

[Message part 1 (text/plain, inline)]

On Mon, Mar 3, 2025 at 2:21 PM Daniel Colascione <dancol <at> dancol.org> wrote:

> 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.
>

To observe this behavior, I was supposed to click not in a text window but
on some other UI control?

[Message part 2 (text/html, inline)]

Message #52 received at 76629 <at> debbugs.gnu.org (full text, mbox):

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

Daniel Colascione <dancol <at> dancol.org> writes:

> On March 3, 2025 11:33:00 AM PST, Stefan Kangas <stefankangas <at> gmail.com> wrote:
>>Daniel Colascione <dancol <at> dancol.org> writes:
>>
>>> 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.
>>
>>[...]
>>
>>> 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.
>>
>>Thanks for taking the time to look into this properly.
>>
>>If no one will volunteer to implement the more involved version, I agree
>>that a defcustom is the best we can do for now.
>
> We can make a menu defoption with 'always and 'never choices for click through, then add an 'auto option later.

SGTM.

Previous Next

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