wl_data_source::dnd_drop_performed clarification
The way I understand the wl_data_source::dnd_drop_performed
specification, compositors should emit this signal whenever a drop happened from the user perspective, regardless whether the destination accepts the drop or not. The only situations when it should not be emitted are when the compositor chooses to cancel the operation because e.g. a timeout or, like mutter does since recently:1, by pressing the ESC
key.
As it stand, Weston, Mutter (and reportedly Sway, too) do not emit this signal if the destination does not accept the offer (tested with nautilus by dragging a file to the top bar). Is that wrong behaviour from the compositors? Should we update the spec to make this more clear?
The reason I'd like to clarify this is that I'd like the GTK Wayland backend to give similar dnd cancel reasons like on X11. While this might not be possible on Wayland in a fine grained manner, I'd love to have at least a differentiation between cancelled and performed but not successful. This in turn is needed to make the Firefox "drop a tab into the nowhere to create a new window" action feasible on Wayland.
cc: @jadahl, @emersion, @carlosg