[Wayland] Ctrl has no effect on drag and drop (DnD), moves instead of copies
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: kevin, Assigned: stransky)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression)
Attachments
(7 files, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
With Firefox Nightly build 20220503094208 on Sway or Mutter, holding Ctrl while dragging things (selected text in an editable text box, tabs, bookmarks, etc.) has no effect. Although a "+" does appear next to the cursor (on Mutter, not Sway), the item is moved rather than copied. To reproduce:
- Open Manage Bookmarks (Ctrl+Shift+O)
- Drag a bookmark from one folder to another, hold Ctrl when releasing the mouse button.
- Observe that the bookmark was moved, rather than copied.
Pushlog https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c38d34be7c3f757510f037fef5a78ea08af32980&tochange=ba378c62cecf6a3048baddde1f9c7d61b45a2914 suggests this was regressed by Bug 1732116
Reporter | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
:stransky, since you are the author of the regressor, bug 1732116, could you take a look?
For more information, please visit auto_nag documentation.
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1732116
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 3•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 4•2 years ago
|
||
Updated•2 years ago
|
Comment 5•2 years ago
|
||
:jhorak is there an update on this patch?
Assignee | ||
Comment 7•2 years ago
|
||
While the patch above is correct there's another underlying issue here.
If we call gdk_drag_status() on Wayland it must be followed by gdk_drag_context_commit_drag_status() to pass D&D action to Wayland compositor.
gdk_drag_context_commit_drag_status() is internal Gtk function and it's called by _gdk_event_emit() after any event handler. So we need to call gdk_drag_status() from drop_motion handler, otherwise compositor uses previous state passed by gdk_drag_status().
Assignee | ||
Comment 8•2 years ago
|
||
- When gdk_drag_context_get_selected_action() returns valid D&D operation, use it instead of default one.
- Add more D&D logging.
Assignee | ||
Comment 9•2 years ago
|
||
D&D uses nested evenet loops to get data from system. Let's track how deep are they nested for diagnostic purpose.
Depends on D154413
Assignee | ||
Comment 10•2 years ago
|
||
Depends on D154414
Assignee | ||
Comment 11•2 years ago
|
||
This is an update to Bug 1730203. We need to answer to D&D inside of D&D move handler due to specific Gtk architecture.
In fix for Bug 1730203 we send the reply but we failed to update D&D status so the reply may be outdated.
In this patch we:
- Set correct D&D state and send reply to D&D motion event
- Move above code to nsDragService (nsDragService::Schedule()) so UpdateDragAction()/ReplyToDragMotion() can be private again.
- Update UpdateDragAction()/ReplyToDragMotion() to use correct GdkDragContext.
- At UpdateDragAction() call gdk_drag_context_get_selected_action() for valid GdkDragContext only.
Depends on D154415
Assignee | ||
Comment 12•2 years ago
|
||
As we handle D&D in time now we can remove the D&D workaround.
It was used to enable D&D until D&D move handler sends reply to system but also enables D&D where should be disabled (like History menu).
Depends on D154416
Assignee | ||
Comment 13•2 years ago
|
||
Due to different D&D handling on X11 and Wayland we should pass only GDK_ACTION_MOVE to gdk_drag_status().
Different D&D operation passed to gdk_drag_status() is returned back by gdk_drag_context_get_selected_action() so
gdk_drag_context_get_selected_action returns value set by gdk_drag_status() and not D&D modifiers set by CTRL/SHIFT
Also pass correct time to gdk_drag_status().
Depends on D154417
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 14•2 years ago
|
||
Depends on D154418
Comment 15•2 years ago
|
||
Comment 16•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d7e9842e0669
https://hg.mozilla.org/mozilla-central/rev/9f7668fe5005
https://hg.mozilla.org/mozilla-central/rev/9579345d486c
https://hg.mozilla.org/mozilla-central/rev/ce14892b50cf
https://hg.mozilla.org/mozilla-central/rev/58cf9a5995f7
https://hg.mozilla.org/mozilla-central/rev/34e69bdbf56e
https://hg.mozilla.org/mozilla-central/rev/674e049eef29
Updated•2 years ago
|
Updated•2 years ago
|
Comment 17•2 years ago
|
||
I managed to reproduce this issue on Firefox 104.0(build ID: 20220818191623) on Ubuntu 22.04, using the STR from the Description. Verified as fixed on Firefox 105.0b4(build ID: 20220828190315) and Nightly 106.0a1(build ID: 20220829214526) on Ubuntu 22.04.
Description
•