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:

1. Open Manage Bookmarks (Ctrl+Shift+O)
2. Drag a bookmark from one folder to another, hold Ctrl when releasing the mouse button.
3. 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

:stransky, since you are the author of the regressor, bug 1732116, could you take a look?
For more information, please visit auto_nag documentation.

Set release status flags based on info from the regressing bug 1732116

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

:jhorak is there an update on this patch?

Will look at it.

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().

• When gdk_drag_context_get_selected_action() returns valid D&D operation, use it instead of default one.
• Add more D&D logging.

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

Depends on D154414

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

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

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

Depends on D154418

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

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.