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

Previous Next

Full log

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)]

Previous Next

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