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

[martin rudalics]

> ​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.

Do you mean that earlier Emacsen behave differently in this regard?

>>> (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?

I think so.  For example if you want to move your frame to that position
on the screen.

> 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).​

IIUC Emacs never was able to do that.  Mouse dragging events so far make
sense only for the one-frame case.  What you want involves much more
trickery: If you have two target frames covering the same screen
position, which one would you choose when releasing the mouse at that
position?  Probably the one higher in the z-order.  But only Emacs 26
can handle that and we would have to write routines to do it.  Or
the one that gets focus during mouse tracking because your window
manager has some sort of focus-follows-mouse installed?  Then you would
have to query the focus when you release the mouse.  Non-trivial.

martin