GNU bug report logs - #28620
Mouse drag event records wrong window for release when crossing frames

Previous Next

Full log

View this message in rfc822 format

From: Robert Weiner <rsw <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 28620 <at> debbugs.gnu.org
Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window
Date: Tue, 3 Oct 2017 20:15:53 -0400

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

On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan <at> idiocy.org> wrote:

> On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote:
> > This happens consistently in testing.  This must be a bug in
> mouse-position
> > for macOS, right?  Why would (mouse-position) still report f1 when f2 is
> > the selected frame?  Maybe this is why I am seeing the wrong frame on
> drag
> > releases too.
>
> As far as I can tell ns_mouse_position returns the frame stored in
> dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however:
>
>     If the user clicks a view that isn’t in the key window, by default
>     the window is brought forward and made key, but the mouse event is
>     not dispatched.
>

​What does "the mouse event is not dispatched mean"?  Does it mean Emacs
never sees the event?  Maybe Emacs sees only that the window has been
selected by the window manager and based on that switches to the selected
window of the frame?

> ​​
>
> ​​
>         https://developer.apple.com/library/content/documentation/
> Cocoa/Conceptual/EventOverview/HandlingMouseEvents/
> HandlingMouseEvents.html
> ​​
>
> ​​
> My guess is that ns_mouse_position needs to get a list of NSWindows,
> ​​
> iterate over them to find out which one the mouse pointer is over,
> ​​
> convert that NSWindow back to an Emacs frame, and set *fp to it before
> ​​
> returning.
>

​The mouse wheel code manages to scroll the proper window that the mouse is
over, even across overlapping frames where the window the mouse is over is
in a frame that is partially behind another frame.  And this happens
without without any click events.  This could be utilized in the click
event code to get this right somehow.

It looks like the EV_TRAILER macro call at the end of the nsterm.c
mouseDown function (which is also called by mouseUp) sets the frame used
for mouse button down, up and scroll wheel events from the variable
emacsframe.  Somehow the value of emacsframe must be set differently for
mouse up events than it is for mouse wheel events since they end up with
different frames for the same mouse positions.

Bob

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