Bugzilla

Oh my, found the issue.

TL;DR: bug 1703490 and bug 1706624 don't work without changing GTK API.

Long version:

In [1] we call `wl_data_device_manager_get_data_device`. According to the Wayland spec[2], there are two important things here:
>  There is one wl_data_device per seat which can be obtained from the global wl_data_device_manager singleton.

and
> wl_data_device_manager::get_data_device: Create a new data device for a given seat.

So if we use the seat form GTK, calling `wl_data_device_manager_get_data_device` creates a second device, with according to spec is undefined behaviour - there should only be one, but now there are two. So Mutter weirdly toggles between them, while Weston strictly uses the last created one (arguably the better behaviour).
There is a GTK API which would give us the GTK data device, so we can add our listeners to it: `gdk_wayland_device_get_data_device`[3]. However, it's not public.

So I see a couple of options here:
 - ask GTK devs to make `gdk_wayland_device_get_data_device` public, allowing us to have a mix of GTK managed DnD and FF managed clipboard
 - revert bug 1703490 and bug 1706624 and continue managing everything ourselves.
 - investigate whether we can make the FF clipboard non-blocking and go fully GTK. This would be IMO the cleanest solution, letting us drop lots of code. But probably also the hardest one. I somewhere read that something like that is being worked on for JS clipboard functions - maybe by now it's somewhat feasible.

Martin, WDYT?

1: https://searchfox.org/mozilla-central/source/widget/gtk/nsClipboardWayland.cpp#499
2: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device_manager
3: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/wayland/gdkdevice-wayland.c#L5448

Oh my, found the issue.

TL;DR: bug 1703490 and bug 1706624 don't work without changing GTK API.

Long version:

In [1] we call `wl_data_device_manager_get_data_device`. According to the Wayland spec[2], there are two important things here:
>  There is one wl_data_device per seat which can be obtained from the global wl_data_device_manager singleton.

and
> wl_data_device_manager::get_data_device: Create a new data device for a given seat.

So if we use the seat form GTK, calling `wl_data_device_manager_get_data_device` creates a second device, with according to spec is undefined behaviour - there should only be one, but now there are two. So Mutter weirdly toggles between them, while Weston strictly uses the last created one (arguably the better behaviour), so there DnD is completely broken atm.
There is a GTK API which would give us the GTK data device, so we can add our listeners to it: `gdk_wayland_device_get_data_device`[3]. However, it's not public.

So I see a couple of options here:
 - ask GTK devs to make `gdk_wayland_device_get_data_device` public, allowing us to have a mix of GTK managed DnD and FF managed clipboard
 - revert bug 1703490 and bug 1706624 and continue managing everything ourselves.
 - investigate whether we can make the FF clipboard non-blocking and go fully GTK. This would be IMO the cleanest solution, letting us drop lots of code. But probably also the hardest one. I somewhere read that something like that is being worked on for JS clipboard functions - maybe by now it's somewhat feasible.

Martin, WDYT?

1: https://searchfox.org/mozilla-central/source/widget/gtk/nsClipboardWayland.cpp#499
2: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device_manager
3: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/wayland/gdkdevice-wayland.c#L5448

Oh my, found the issue.

TL;DR: bug 1703490 and bug 1706624 don't work without changing GTK API.

Long version:

In [1] we call `wl_data_device_manager_get_data_device`. According to the Wayland spec[2], there are two important things here:
>  There is one wl_data_device per seat which can be obtained from the global wl_data_device_manager singleton.

and
> wl_data_device_manager::get_data_device: Create a new data device for a given seat.

So if we use the seat form GTK, calling `wl_data_device_manager_get_data_device` creates a second device, which according to spec is undefined behaviour - there should only be one, but now there are two. So Mutter weirdly toggles between them, while Weston strictly uses the last created one (arguably the better behaviour), so there DnD is completely broken atm.
There is a GTK API which would give us the GTK data device, so we can add our listeners to it: `gdk_wayland_device_get_data_device`[3]. However, it's not public.

So I see a couple of options here:
 - ask GTK devs to make `gdk_wayland_device_get_data_device` public, allowing us to have a mix of GTK managed DnD and FF managed clipboard
 - revert bug 1703490 and bug 1706624 and continue managing everything ourselves.
 - investigate whether we can make the FF clipboard non-blocking and go fully GTK. This would be IMO the cleanest solution, letting us drop lots of code. But probably also the hardest one. I somewhere read that something like that is being worked on for JS clipboard functions - maybe by now it's somewhat feasible.

Martin, WDYT?

1: https://searchfox.org/mozilla-central/source/widget/gtk/nsClipboardWayland.cpp#499
2: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device_manager
3: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/wayland/gdkdevice-wayland.c#L5448