GNU bug report logs - #31546
27.0.50; macOS child frames with no mode-line mouse click problem

Previous Next

Full log

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

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 31546 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31546: 27.0.50; macOS child frames with no mode-line mouse
 click problem
Date: Sun, 27 May 2018 22:24:29 +0100

On Sun, May 27, 2018 at 11:52:36AM -0700, Aaron Jensen wrote:
> One more clue: On a frame that doesn't accept focus on a mac, a
> single click results in a mouse-movement getting fired immediately
> after the down-mouse-1. A single click on a normal frame does not do
> this. This is why this issue doesn't repro on a frame that accepts
> focus. Something about how the non-focusable frames are causes them
> to get mouse moves immediately after a click. This means that the
> transient map created in mouse-drag-track immediately gets invoked
> with a mouse-movement, which is what triggers the scroll. As
> mentioned earlier in the thread, this is only true if the mouse has
> moved since the last click. That means if you click twice in row,
> only the first click will get a mouse-movement fired after it. If
> you then move the mouse and click again, it'll fire the down-mouse-1
> then the mouse-movement again.
> 
> Perhaps someone who understands the way that mouse tracking works on
> mac would know why a frame that doesn't accept focus behaves
> differently? It's as if the non-focusable window only gets notified
> of a mouse's new position whenever a click happens, so every click
> is as if the click happened and then the mouse moved to that
> position.

Hmm, OK. So normally the first click on a non‐selected NSWindow makes
that NSWindow key (i.e. it selects the frame without registering an
emacs mouse down event), but by enabling no-accept-focus we prevent
the NSWindow becoming key, and the click is then actually registered
as a mouseDown event (therefore causing an Emacs mouse down event).

There’s also a mouseMoved method that says ‘Tell emacs the mouse has
moved.’, but I’m unsure how it does that, or if it’s even relevant. I
don’t think it sends any events unless you have
mouse-autoselect-window set. mouseDragged just calls mouseMoved, so
Emacs must be doing its own mouse move/drag detection elsewhere.

mouseMoved is called every time the mouse pointer moves on an Emacs
frame whether it’s selected or not.

Is it possible a move is being registered because the click was in
frame X, but frame Y is selected? I noticed while testing this that
ns_mouse_position is sometimes (always?) called for multiple frames
when one mouse click has been made.

And, actually, I’m not sure if it’s a bug, but the X and Y coords
returned are for the frame ns-mouse-position is being run from, rather
than from the frame it lists in its output...

*sigh* try this:

modified   src/nsterm.m
@@ -2547,7 +2547,7 @@ so some key presses (TAB) are swallowed by the system. */
 
   if (f && FRAME_NS_P (f))
     {
-      view = FRAME_NS_VIEW (*fp);
+      view = FRAME_NS_VIEW (f);
 
       position = [[view window] mouseLocationOutsideOfEventStream];
       position = [view convertPoint: position fromView: nil];


-- 
Alan Third

Previous Next

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