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.