Re: Possible Bug: Mouse drag event records wrong window for release when crossing frames

[Robert Weiner]

On Wed, Sep 27, 2017 at 4:11 AM, martin rudalics <address@hidden> wrote:

> With Emacs 25.2 under MacOS 10.12, I use a mouse key that has bindings on
> both its depress and release states.  The depress is in a frame with 2
> windows (one showing *Buffer List* and the other showing hmouse-drv.el).
> The depress occurs in the *Buffer List* window.
>
> The release occurs in another frame and the release window is showing
> hui-window.el.

Are the frames occupying separate areas on your screen or do they
intersect?

​The behavior is the same either way.  It is definitely a bug in Emacs 25.2 and 25.3 as I have confirmed it on both MacOS and Windows 7 using just default mouse-1 ​drags between frames.

> Here is the drag event generated.  Element 2 shows the proper depress
> window but element 3 shows the depress frame rather than the release
> frame.  And element 3 has a frame rather than a window as its first
> argument even though the Elisp manual says it should be a window.

IIRC it's a frame when there's no suitable window at the specified
position.  This is largely undocumented and has been sometimes even used
wrongly in the Emacs code base itself.

​Yes, I found this documented in the Emacs Lisp manual, i.e. that posn-window can return a frame, but it is not documented in the code nor do all the posn-* and mouse point setting functions handle frame results from posn-window.  I have some suggested fixes I will post for this but the bug we are talking about here is generated in the C event-handling code, I believe.​

> (drag-mouse-2 (#<window 90 on *Buffer List*> 2905 (88 . 467) 4050744642 nil
> 2905 (12 . 33) nil (4 . 5) (7 . 14)) (#<frame hmouse-drv.el
> "/Users/bk/Dropbox/emacs/hyperbole/" 0x102f5bde8> nil (-1373 . 463)
> 4050749802))

The start event seems to look OK.  As for the end event, an X-coordinate
of -1373 does not look reasonable.

​Right.  Is a negative value ever valid in this context?

​

  Please post results for dragging from
one to another window on the same frame.

​That works fine, so I'd rather not complicate things with that.

Eli, could you help us debug this or at least point us to where to set a breakpoint and what internal structures to look at?

My claim is that if you put 2 frames on screen (start with non-overlapping) and drag mouse-1 from the text area of one to the second, that the drag event generated upon the release of mouse-1 will contain frame1 rather than frame2 (where the release happened).​

The need for this is in some code that selects a buffer or file name and displays it in the window of the drag release.  It works within a single frame but fails across frames due to this issue.

Bob