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

Previous Next

Full log

Message #26 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: Tue, 3 Oct 2017 23:40:17 +0100

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.

        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.

That way it should return the frame the mouse is over, rather than the
last one that received a click event.

I’m not sure what happens if the mouse isn’t over an emacs frame...
Does it just return *fp unchanged?
-- 
Alan Third

Previous Next

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