Bug 469644

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/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.