bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Alan Third <alan@idiocy.org>]

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