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

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

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

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.

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.

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

Has anyone seen this behavior before or know what's going on.  I'm just
trying to write a simple function that selects a buffer from one window and
puts it in another window which may be in another frame.

Thanks,

Bob

[-- Attachment #2: Type: text/html, Size: 1688 bytes --]

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

[martin rudalics]

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

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

 > (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.  Please post results for dragging from
one to another window on the same frame.

Thanks, martin

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

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

On Wed, Sep 27, 2017 at 4:11 AM, martin rudalics <rudalics@gmx.at> 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

[-- Attachment #2: Type: text/html, Size: 4904 bytes --]

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

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

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

On Fri, Sep 29, 2017 at 4:34 AM, martin rudalics <rudalics@gmx.at> 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
​

[-- Attachment #2: Type: text/html, Size: 7812 bytes --]

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

[martin rudalics]

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

I might be missing something but sampling the mouse position and having
the release command set the selected window are two completely different
pairs of shoes.  For example, the ‘mouse-autoselect-window’ mechanism
relies on the window system/manager to cooperate in order to select
another frame's windows.  With "normal" mouse movements.

martin

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

[Stefan Monnier]

> Or the one that gets focus during mouse tracking because your window
> manager has some sort of focus-follows-mouse installed?

FWIW, on my system (ctwm with its default policy of focus following the
mouse), the focus does *not* follow the mouse during a drag.


        Stefan

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

[martin rudalics]

 > FWIW, on my system (ctwm with its default policy of focus following the
 > mouse), the focus does *not* follow the mouse during a drag.

Neither on mine.

martin

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

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Fri, Sep 29, 2017 at 2:20 PM, martin rudalics <rudalics@gmx.at> wrote:

> > FWIW, on my system (ctwm with its default policy of focus following the
> > mouse), the focus does *not* follow the mouse during a drag.
>
> Neither on mine.


​On a Mac with Emacs 25.3 with focus-follows-mouse​ and
mouse-autoselect-window both set true, I get inconsistent behavior.
Sometimes when moving between non-overlapping frames, the focus follows and
other times it does not.  It could be speed-related (I know there is a
default dwell time) or the path my mouse traverses but I found the overall
behavior unusable and turned it off.

Bob


>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 1679 bytes --]

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

[Stefan Monnier]

> ​On a Mac with Emacs 25.3 with focus-follows-mouse​ and
> mouse-autoselect-window both set true, I get inconsistent behavior.

Beware: `focus-follows-mouse` is a variable which does not *cause* the
focus to follow the mouse.  Instead it has no other effect than to
inform Emacs that it's running in an environment where the
window-manager (or equivalent) uses the policy that the focus should
follow the mouse.


        Stefan

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

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Fri, Sep 29, 2017 at 3:20 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > ​On a Mac with Emacs 25.3 with focus-follows-mouse​ and
> > mouse-autoselect-window both set true, I get inconsistent behavior.
>
> Beware: `focus-follows-mouse` is a variable which does not *cause* the
> focus to follow the mouse.  Instead it has no other effect than to
> inform Emacs that it's running in an environment where the
> window-manager (or equivalent) uses the policy that the focus should
> follow the mouse.
>

​In other words, it has no use under the macOS window manager.
I just want to get drag events that work across frames.

Bob
​

>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 1797 bytes --]