[Wayland] Crash when 'ALT' is pressed during drop
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
People
(Reporter: stransky, Assigned: stransky)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.
Assignee | ||
Comment 1•3 years ago
|
||
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")
Assignee | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
This is Gnome only bug, KWin works as expected.
Assignee | ||
Comment 4•3 years ago
|
||
Comment 5•3 years ago
|
||
(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
Assignee | ||
Comment 6•3 years ago
|
||
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.
Comment 7•3 years ago
|
||
(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.
Assignee | ||
Comment 8•3 years ago
|
||
(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.
Comment 9•3 years ago
|
||
(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.
Comment 10•3 years ago
|
||
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.
Comment 11•3 years ago
|
||
Ok, Martin you were right, it's a Mutter issue. Opened https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2043
Comment 12•3 years ago
|
||
This is now fixed upstream and backported to Gnome 41, 40 and 3.38.
Assignee | ||
Comment 13•3 years ago
|
||
Okay, Thanks!
Description
•