bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

Martin:

Thanks for commenting on this and sharing some of your extensive knowledge on window event handling and Emacs.

On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics <rudalics@gmx.at> wrote:

> ​I think it is a feature that Emacs receives an event for this but a defect
> that it can't distinguish when f2 is atop an external window or not and
> thus whether the event was actually directed at f2 or not.

‘mouse-drag-region’ is an Emacs internal function, so it's no defect.
If it were not internal, Emacs would have to be either able to poll the
other window's application as to whether it supports dropping an Emacs
internal string or convert that string to some appropriate coding that
other applications understand.  Neither of these has been done yet and
it will be non-trivial to do that for our various platforms.

​Ok, that indicates that drag-and-drop from Emacs to external applications is unlikely but it still leaves the issue of recognizing whether a drag release event maps to an Emacs frame or not (when the frame is covered by an external app's window).  I already have code that recognizes this in Lisp; we should make it a primitive so the drag release code in Emacs could report more useful and accurate information in drag release events.

I guess you are saying that Emacs drag events must start and end within Emacs frames.  I think about it a bit differently.  Since the mouse can move in and out of Emacs frames and release events can occur (in logical Z-ordered OS window space) outside of Emacs, yet still register with Emacs (when the release occurs within the geometry of a frame but the frame is covered by another app's window), I think Emacs event handling should return different information when the release frame is not the topmost OS-level window at the point of release.  Then handler code could dispatch as necessary.

I already have Lisp code doing useful things with such information (presently, I have to adjust the drag release event information).  So I know it would be helpful to have this as default Emacs event reporting behavior.

​​

​​

> ​Just FYI, I am using the macOS window manager, not X, though as you note,

​​

> it is an issue there too.

​​

> The application-level window managers must have a z-ordering for all

​​

> windows in order to be able to select and raise windows when they are

​​

> behind others.  So you are saying that they don't publish this information

​​

> in any useful way that Emacs can obtain, right?

​​

​​

All I can say is that when you nowadays try to obtain information on

​​

whether a window is really visible under X, chances are that you don't

​​

g

​​

e

​​

t

​​

​​

i

​​

t

​​

.

​Each window has a 'visible' attribute.  Are you saying this is not accurate these days?​

​​​

​

  Querying the z-order will only tell you something like "window

​​

Y cannot obscure window X because it's lower in the z-order".

​We just want to know when given a screen position whether an Emacs frame is topmost at that position or not.​

​​​

​​

​​

> Part of the issue is that the macOS window manager uses click-to-focus, so

​​

> the release event of the drag does not switch focus to the application

​​

> whose window the release falls upon.

​​

​​

As Stefan already mentioned earlier: With a drag operation usually no

​​

focus shifting occurs anyway.

For the interactive things I am doing, I find that selecting the window of mouse release is always best but I agree it is not necessary in all instances.

​​

​

> However, in drag-n-drop operations,

​​

> the window manager automatically switches focus to any compatible

​​

> application that the mouse moves over (after a delay) so that the right

​​

> application receives the drop (based on Z-order).

​​

​​

It's completely up to the window manager which polls the application(s)

​​

whether they are ready to receive the object to drop.  Emacs is not

​​

involved in that process.  It would be involved only to tell whether it

​​

would accept such a string when it's the target of a drop.

​I understand that.  I was just noting that there is an example of a drag release event handler that selects the window of release as a standard part of its operation.

​​

​​

​​

> Mouse wheel events are also delivered to the topmost Z-order window without

​​

> either raising the window or switching focus.

​​

​​

Mouse wheel events are completely different and highly window system

​​

dependent.  Sometimes they get caught before Emacs sees them at all and

​​

get transformed to scroll bar thumb drag events to the owner of the

​​

scroll bar nearest to the mouse cursor at the time the wheel gets

​​

scrolled.

​Again, I was just providing context of what might be possible based on other event handling that occurs already in Emacs under macOS.​

​​

​

​​

> So the window manager always knows where it should deliver

​​

​​

... it never "knows".  Some make better guesses and some make worse ...

​On macOS the scroll wheel events seem to go to the right window 100% of the time from what I have seen.​

​​

​

​​

> What would the pseudo-code

​​

> look like to check whether or not an Emacs frame was uppermost at the point

​​

> of mouse release?

​​

​​

(1) ‘frame-list-z-order’ would have to be able to return all windows on

​​

your system

​Is it likely we could build a multi-platform primitive ​that would supply that information given what you have said?

​​​

​​

and (2) a function would be needed to get the attributes of

​​

those windows.

​2 seems straightforward.

Bob

​​