STEPS TO REPRODUCE 1. save a file with Firefox - I saved a .jpg file. Plasma shows a notification with a file icon after saving the file. 2. drag the file icon from the notification and try to drop it on Discord 3. OBSERVED RESULT the mouse pointer changes to "not allowed" mode while we hover over Discord and we cannot drop the file. EXPECTED RESULT drag-and-drop works SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Graphics Platform: Wayland
Cannot reproduce on X11.
Could reproduce in the past on Plasma 5, but now this works for me on Wayland in Plasma 6; probably fixed by Qt changes.
This bug persists on Plasma 6; can reproduce on Wayland, cannot on X11. Another way to reproduce: 1. take a screenshot with Spectacle by pressing shift+printscreen - Plasma shows a notification with a preview of the screenshot 2. drag the preview of the screenshot from the notification and try to drop it on another app - Discord or an internet browser (tested Firefox and Vivaldi on my system), for example Result: we cannot drop the screenshot on another app Operating System: Arch Linux KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Graphics Platform: Wayland
Are these apps running as Flatpaks, or native packages?
All apps mentioned in comment 3 are native packages and run natively on Wayland, not on Xwayland.
Ok, I can reproduce the issue. Either I was testing wrong before, or else it regressed.
I can reproduce the issue neither in 6.1 nor in master
Created attachment 171889 [details] screenshot of Discord I can reproduce consistently both cases (described in comment 0 and comment 3) with chromium, vivaldi and discord. Can reproduce both cases with Firefox too, but inconsistently. Sometimes DnD works, sometimes it fails. As we can see in the screenshot attached to this comment, Discord even shows the message indicating that a file dragged from a notification can be dropped, but the mouse pointer enters in "not-allowed" mode and the droppping fails. Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Graphics Platform: Wayland
So to clarify my previous ability to reproduce the issue: - I can reproduce it with Discord, in either native Wayland or XWayland more, as a Flatpak or a native package. - I can reproduce it with chromium, in either native Wayland or XWayland more, as a Flatpak or a native package. - I cannot reproduce it in Firefox in any case. So it seems like perhaps the problem is Chromium-specific. Regardless, in Chromium and Discord I get the exact same result you do, Patrick: dragging-and-dropping a screenshot from Plasma's notification produces a red "can't drop here" cursor even though the content on the page visible changes in a way that looks like it will accept the drag.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6156
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4548
Git commit d6016d8401c4a28928c7d641df73fbddec83871d by David Edmundson. Committed on 23/07/2024 at 08:59. Pushed by davidedmundson into branch 'master'. notifications: When doing a drag and drop, set the supported action to cpoy By default QDrag::exec performs a drag where the allowed actions are only "move". The mimedata for a screenshot is a URI list to the file, dragging and dropping should not move the original file. Equally importantly if we want to share a file, that's effectively a copy. Some clients will rightfully not accept a URI list with the only action being move. Testing done: Screenshot taken with the spectacle global shortcut, then drag from that into the Electron app "Discord" M +1 -1 applets/notifications/draghelper.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/d6016d8401c4a28928c7d641df73fbddec83871d
Git commit cf41b532579cb010fac218e186cf3df8968f6bbf by David Edmundson, on behalf of David Edmundson. Committed on 23/07/2024 at 09:00. Pushed by davidedmundson into branch 'Plasma/6.1'. notifications: When doing a drag and drop, set the supported action to cpoy By default QDrag::exec performs a drag where the allowed actions are only "move". The mimedata for a screenshot is a URI list to the file, dragging and dropping should not move the original file. Equally importantly if we want to share a file, that's effectively a copy. Some clients will rightfully not accept a URI list with the only action being move. Testing done: Screenshot taken with the spectacle global shortcut, then drag from that into the Electron app "Discord" (cherry picked from commit d6016d8401c4a28928c7d641df73fbddec83871d) e41d94b3 notifications: When doing a drag and drop, set the supported action to cpoy Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +1 -1 applets/notifications/draghelper.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/cf41b532579cb010fac218e186cf3df8968f6bbf
Git commit 6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7 by Vlad Zahorodnii, on behalf of David Edmundson. Committed on 23/07/2024 at 12:50. Pushed by vladz into branch 'master'. wayland: Avoid klipper loop with existing but empty clipboards In default settings if the clipboard or selection is empty klipper will try to replace it with cached data. To avoid an occurring race condition if a client deletes and then recreates a selection kwin will deny klipper if another mimedata is present at the time it tried to replace an empty clipboard. Klipper also considers the presence of a valid mime data without any offers to be an empty clipboard, whereas kwin did not. If a super weird client set the clipboard to a valid entry with no offers, klipper would get into an infinite loop of trying to set it's own selection for it to be continually denied with no other valid offer from klipper's perspective ever received. M +4 -3 src/wayland/seat.cpp https://invent.kde.org/plasma/kwin/-/commit/6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7
Git commit c91040d3deee8a2028562451fa056c002f35ae42 by David Edmundson, on behalf of David Edmundson. Committed on 23/07/2024 at 13:13. Pushed by davidedmundson into branch 'Plasma/6.1'. wayland: Avoid klipper loop with existing but empty clipboards In default settings if the clipboard or selection is empty klipper will try to replace it with cached data. To avoid an occurring race condition if a client deletes and then recreates a selection kwin will deny klipper if another mimedata is present at the time it tried to replace an empty clipboard. Klipper also considers the presence of a valid mime data without any offers to be an empty clipboard, whereas kwin did not. If a super weird client set the clipboard to a valid entry with no offers, klipper would get into an infinite loop of trying to set it's own selection for it to be continually denied with no other valid offer from klipper's perspective ever received. (cherry picked from commit 6943fab2c1c46eb15e0018ae3419c0d43eb3c8d7) Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +4 -3 src/wayland/seat.cpp https://invent.kde.org/plasma/kwin/-/commit/c91040d3deee8a2028562451fa056c002f35ae42
I have built the branch 6.1 of kwin on my Arch Linux with these commands: $ git clone https://invent.kde.org/plasma/kwin.git $ cd kwin $ git checkout remotes/origin/Plasma/6.1 $ mkdir build && cd build $ cmake .. $ make -j 4 $ sudo make install However, the bug persists. I suspect my system is still using kwin from its repositories instead of the one built locally. Please could anyone tell me how to replace kwin from the repositories with the one built locally? Thanks.
[path to built-from-source kwin_wayland binary] --replace
Thanks, Nate. After my commands, the files of the built-from-source kwin are installed to the same location than the ones of kwin from Arch repos. However, the bug persists when running the built-from-source kwin.
Nervermind. I need to rebuild plasma-workspace too.