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

[martin rudalics]

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