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