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

[martin rudalics <rudalics@gmx.at>]

 > ​Yes, you would need to follow a common drag-and-drop protocol.
 > I don't understand why that is an issue if that is what you want
 > to do.

Wasn't that something _you_ wanted to do?  If not then we can obviously
ignore it.

 > For programmatic purposes when Emacs receives a mouse button
 > drag release event, we only care about whether the topmost
 > window-system window at the point of release is an Emacs frame
 > or not.  If at that point, it is occluded by another window,
 > we don't care how transparent that window is and whether the
 > Emacs frame can be "seen" but only whether it is logically
 > the window clicked upon.  Again, even if it is not, we can
 > process the event as if it were *if we so choose* but having
 > the choice is the key issue here.

So I warned here about possible problems with "visibility" once and will
drop this issue.

 >> At least for top-level windows.  This will work as long a child windows
 >> ​​
 >> are fully contained by their parents which IIUC is not necessarily true
 >> ​​
 >> for macOS systems.
 >
 >
 > ​Could you give a concrete example of where this might be a problem
 > so I could test code against it?

Hardly.  Child windows are a separate problem because, for example, on X
you currently cannot drop files on them - the drop goes to the parent
window instead.

 >>> and (2) a function would be needed to get the attributes of
 >> ​
 >> ​​
 >>   those windows.
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >>
 >
 > ​I have figured that part out from the macOS APIs.

Window attributes are a problem on X.  You will learn about that as soon
as you try to adapt your code for it.

martin