1904265 - [Sway] DataTransfer.dropEffect does not change when holding ctrl or shift

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect, P3)

Description

[Mathijs Saey]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0
OS: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0 (I'm using Gentoo's prebuilt firefox, firefox-bin).
Backend: Wayland (Sway), MOZ_ENABLE_WAYLAND=1 is set.

1. Go to https://jsfiddle.net/1z3k58pc/
2. Drag the element at the top to the drop zone, don't drop it yet
3. Hold ctrl to set the dropEffect to "copy" (I have also tried using alt and shift, and ctrl + shift, with the same result)
4. Drop the element over the drop zone.

Actual results:

The element is moved to the drop zone. This is the case as the dropEffect element is set to "move".

Expected results:

Holding ctrl should set the dropEffect to "copy", causing a copy of the element to be created in the drop zone.

This behavior occurs on an X11 build of Firefox (holding ctrl), and on an OSX build of firefox (holding alt). However, it seems to be broken on wayland.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Can you try nested mutter compositor?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
Thanks.

Comment 3

[Mathijs Saey]

Firefox behaves as expected in mutter, so this seems to be a sway/wlroots bug. I will report it there. Thanks for the pointer.

Comment 4

[Mathijs Saey]

For anybody that stumbles upon this in the future, here is the relevant sway bug report: https://github.com/swaywm/sway/issues/8219