Difficulties with Wayland D&D protocol - D&D source persistence

Carlos Garnacho carlosg at gnome.org
Mon Oct 24 10:29:37 UTC 2022

Hi Martin,

On Mon, Oct 24, 2022 at 11:43 AM Martin Stransky <stransky at redhat.com> wrote:
> Hi folks,
> I'd like to point out how Wayland D&D protocol limits real life
> applications.
> Main limitation is a requirement that D&D source window has to be kept
> opened and D&D is cancelled otherwise.
> That's especially painful with popups. See this Mozilla bug and video
> attached there [1].

OTOH it is also what makes DnD neatly abort if the source surface and
its ongoing operations got legitimately destroyed.

> What's the problem?
> - When a popup window is source of D&D (a bookmark entry on the example
> here), we can't close it.
> - It's difficult to do D&D to another popup as the source one has to me
> kept opened. That means we need to show popups which are not intended to
> be shown together:
>   - if the popups are adjacent, xdg-positoner can be used.
>   - if the popups are not adjacent (an example on the clip),
> wl_subsurface popup has to be used with its consequences (buggy
> compositor/gtk3 implementation).
> So may be the D&D source persistence condition relaxed?

To allow a fix for this case, I think it would be more backwards
compatible and coherent to relax wl_data_device.start_drag conditions,
so that it's only required that the serial/grab is on a surface of the
same client, and a different source surface may be used. Firefox could
then pass the toplevel surface as the drag source. This way lifetime
correctness is guaranteed, and "snap back" animations on failed DnD
have a surface to return to.


More information about the wayland-devel mailing list