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

[Alan Third]

On Wed, Oct 04, 2017 at 01:26:18PM -0400, Robert Weiner wrote:
> On Wed, Oct 4, 2017 at 12:30 PM, Alan Third <alan@idiocy.org> wrote:
> 
> > 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@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.
> >
> 
> ​So how is it that Emacs processes a drag event when the mouse button is
> released in the new frame if it never sees the mouseUp (drag release)
> event?​  If I drag across frames, on mouseUp, the key binding associated
> with mouseUp (mouse-1 as opposed to down-mouse-1 is run).

The NSEvent is delivered to the EmacsView belonging to the frame where
the drag was initiated. I don’t think there’s anything we can do to
change that.

> > 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).
> >
> 
> ​Can you show some sample code that would make macOS send the mouse drag
> release event to the frame under the mouse pointer just as the scroll wheel
> code does.  I have looked at this mouseUp code in nsterm.m but cannot get
> it to do this.  I have managed to inject a focus in event to the mouseUp​
> function and make its event frame the key frame (selected frame) but its
> event frame is the wrong one (it always has the frame of the mouseDown
> event).

I don’t believe it’s possible. As I described before we’d have to do
something like:

    [...] 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 [return it].

> > AFAICT Emacs does the right thing here, exactly the same thing as
> > every other macOS app.
> >
> ​As Eli noted, this does not happen under MS Windows.  I want to have
> behavior that allows for drags across frames.  The present code does not,
> so whether it is consistent with Mac UI guidelines, it is not useful for
> that purpose.  I would like your help in figuring out how to enable such
> behavior as you seem to understand the macOS event flow well.

But which behaviour? I can’t work out exactly what we’re talking about
here. Are you trying to get cross‐frame dragging working or are you
genuinely concerned that Emacs doesn’t receive a click event when the
frame is selected using the mouse? These seem like two different
things to me.

> > There’s nothing fancy here, emacsframe is an instance variable
> > associated with the EmacsView that macOS sends the mouse event to.
> 
> 
> ​So show me how and where I could set that variable to the frame of the
> mouse position at the point of mouseUp​ and I will test it and let people
> know if it works.

Fns_frame_list_z_order in nsfns.m does some of what’s described
above... But...

It looks like there’s maybe a neater way to get the current frame
under the mouse...

    Lisp_Object frame = Qnil;
    NSWindow *w = [NSApp windowWithWindowNumber:
                         [NSWindow windowNumberAtPoint:[NSEvent mouseLocation]
                           belowWindowWithWindowNumber:0]];
    if (w != nil)
      XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe);

I’ve not tested this, so it may not work at all. Note that [NSEvent
mouseLocation] returns an NSPoint indicating where the mouse is *right
now*. It would probably be more sensible to use any co‐ordinates
provided by the event itself.
-- 
Alan Third