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

[martin rudalics <rudalics@gmx.at>]

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

 > ​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
get it.  Querying the z-order will only tell you something like "window
Y cannot obscure window X because it's lower in the z-order".

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

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

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

 > So the window manager always knows where it should deliver

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

 > 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 and (2) a function would be needed to get the attributes of
those windows.

martin