We crash with protocol error when 'ALT' is pressed during drop operation and 'hand' cursor changes to '?'.

Looks like we don't cover 'drag ask' scenario correctly.

This looks to be a bug in mutter, I can't reproduce it on KWim. We clearly state we don't want 'ask' but it's still selected by mutter:

[2618374.932] wl_data_offer@4278190081.action(4)
[2618375.011] -> wl_data_offer@4278190081.set_actions(7, 2)
[2618375.020] -> wl_data_offer@4278190081.accept(25200, "text/plain")

Filed as https://gitlab.gnome.org/GNOME/mutter/-/issues/1952

This is Gnome only bug, KWin works as expected.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #1)

This looks to be a bug in mutter, I can't reproduce it on KWim. We clearly state we don't want 'ask' but it's still selected by mutter:

[2618374.932] wl_data_offer@4278190081.action(4)
[2618375.011] -> wl_data_offer@4278190081.set_actions(7, 2)
[2618375.020] -> wl_data_offer@4278190081.accept(25200, "text/plain")

set_actions(7, 2) does allow ASK because 7 = 4 (WL_DATA_DEVICE_MANAGER_DND_ACTION_ASK) + 2 (WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE) + 1 (WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY). In the sync clipboard we set it to 3 [1] and Mutter behaves as expected. Apparently Kwin just doesn't use ALT to force ASK. I can't see where we limit which actions GTK can use, so we need to fix that in the async clipboard.

1: https://searchfox.org/mozilla-central/source/widget/gtk/nsClipboardWayland.cpp#392-393

Well, according to spec [1] when wl_data_offer::action is sent client needs to reply with selected action. Firefox does that with selected action '2' but that's ignored and mutter selects ASK anyway...so that looks like Mutter bug to me.

[1] https://wayland.freedesktop.org/docs/html/apa.html

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

Well, according to spec [1] when wl_data_offer::action is sent client needs to reply with selected action. Firefox does that with selected action '2' but that's ignored and mutter selects ASK anyway...so that looks like Mutter bug to me.

Reading the spec I'm actually not sure. So there is:

wl_data_offer::set_actions:
...
While managing an "ask" action, the destination drag-and-drop client may perform further wl_data_offer.receive requests, and is expected to perform one last wl_data_offer.set_actions request with a preferred action other than "ask" (and optionally wl_data_offer.accept) before requesting wl_data_offer.finish, in order to convey the action selected by the user. If the preferred action is not in the wl_data_offer.source_actions mask, an error will be raised.
...

and

wl_data_offer::action:
...
Upon "ask" actions, it is expected that the drag-and-drop destination may potentially choose a different action and/or mime type, based on wl_data_offer.source_actions and finally chosen by the user (e.g. popping up a menu with the available options). The final wl_data_offer.set_actions and wl_data_offer.accept requests must happen before the call to wl_data_offer.finish.
...

So IIUC the debug log looks just fine - Mutter sets ask and FF responds with a final preferred action before accepting and finishing the drop. Will dig a bit into how GTK3 handles this case.

(In reply to Robert Mader [:rmader] from comment #7)

So IIUC the debug log looks just fine - Mutter sets ask and FF responds with a final preferred action before accepting and finishing the drop. Will dig a bit into how GTK3 handles this case.

I didn't attach the full log, it's confirmed / dropped later. Mutter terminated Firefox when D&D was finished.
Anyway, what does Mutter expects anyway? I don't understand what can be done on FF side to fix that, we use standard Gtk D&D API and there isn't anything special here.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #8)

I didn't attach the full log, it's confirmed / dropped later. Mutter terminated Firefox when D&D was finished.
Anyway, what does Mutter expects anyway? I don't understand what can be done on FF side to fix that, we use standard Gtk D&D API and there isn't anything special here.

I'm also still unsure where the issue is - Firefox, GTK, Mutter or even a combination of bugs. I've been digging into it today with no success yet, will continue tomorrow.

Slowly getting closer to what's wrong here. First important observation: were appear to successfully finish the drop and destroy the object (from the client side), with and without 'ask'. However, in case of 'ask', we then try to access the object again and thus crash in https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/connection.c#L915-920.

Still digging.

Ok, Martin you were right, it's a Mutter issue. Opened https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2043

This is now fixed upstream and backported to Gnome 41, 40 and 3.38.

Okay, Thanks!