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

Previous Next

Full log

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

From: Alan Third <alan <at> idiocy.org>
To: rswgnu <at> gmail.com
Cc: 28620 <at> debbugs.gnu.org
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag
 event records wrong release window
Date: Wed, 4 Oct 2017 17:30:48 +0100

On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote:
> On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan <at> idiocy.org> wrote:
> > 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?

Precisely that.

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

The mouse wheel code is also handled in mouseDown, the difference is
that macOS always sends the mouse wheel event to the emacs frame under
the mouse pointer, whereas the mouse click event is not sent when the
frame is not already key (i.e. selected).

AFAICT Emacs does the right thing here, exactly the same thing as
every other macOS app.

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

There’s nothing fancy here, emacsframe is an instance variable
associated with the EmacsView that macOS sends the mouse event to.

-- 
Alan Third

Previous Next

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