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

[Robert Weiner]

On Fri, Sep 29, 2017 at 4:34 AM, martin rudalics <address@hidden> wrote:

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

​No, just that I tested only with those versions.

​

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

​Ok.

​

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

​This needs to be fixed as it is a very natural gesture to

move between frames.  For the text area, this is moving

between windows which just happen to occupy different frames.

​

  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.

​Yes.  It may be easier to think of it in terms of the window

of release rather than the frame​ as one will almost always

need to know the window as well.

​​

One initial way to decrease the complexity is to make this work

only when both the depress and release commands set the selected

window.  Then the posn- functions would have a unique window to

report.

​​

  But only Emacs 26

​​

can handle that and we would have to write routines to do it.

​Ok

.

​​

 

​​

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.

​See above.

Thanks much for the feedback.  I can say that if this is

implemented, it will lead to improved user interfaces and

faster inter-frame control in many instances.

Bob

​