SUMMARY Spectacle copies empty object to clipboard instead of image when Copy image to clipboard is selected in settings STEPS TO REPRODUCE 1. Take a screenshot 2. Screenshot should be copied in the clipboard 3. Empty object (row) shown in the clipboard OBSERVED RESULT Empty object (row) shown in the clipboard EXPECTED RESULT Screenshot in the clipboard as the current item SOFTWARE/OS VERSIONS Operating System: KDE neon User Edition KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.14.0-24-generic (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION It used to definitely work recently, so I would expect this to be some recent change. Either in SPectacle or the clipboard itself, but clipboard seems to be working alright with other apps.
Created attachment 183750 [details] the empty object in the clipboard after Spectacle pushed "screenshot" into it - the displayed QR code maybe it will be easier to debug this way
I'm not able to reproduce this with Spectacle 6.4.3 and Plasma 6.4.3, nor with Spectacle 6.4.3 and git-master To narrow things down, can you share screenshots of the settings for Spectacle - the General and Image Savings pages? Thanks!
Created attachment 183870 [details] general
Created attachment 183871 [details] image options
Thanks for sharing your Spectacle settings. With those, I still can't reproduce this on git-master or Neon User Edition. Out of curiosity, if you click the blank clipboard entry, and paste it somewhere, does an image get pasted or nothing? I'm wondering if the image was actually copied and the clipboard isn't displaying the thumbnail.
I just had this happen on Solus, Plasma 6.4.3. I copied the image with the button in Spectacles image preview. There was an empty row in the clipboard. Selecting it and pasting copies nothing, the row is blank (not just missing a preview) Using the same steps, I can't reproduce this on git-master, so let's call this fixed in Plasma 6.5.0. If you still see the same bug in that version of Plasma, when it becomes available on your system, feel free to reopen this bug. Thanks!
If I click to copy icon, then it works. It seems like the second time it gets transferred to the clipboard correctly.
(In reply to TraceyC from comment #6) > I just had this happen on Solus, Plasma 6.4.3. I copied the image with the > button in Spectacles image preview. > There was an empty row in the clipboard. Selecting it and pasting copies > nothing, the row is blank (not just missing a preview) > > Using the same steps, I can't reproduce this on git-master, so let's call > this fixed in Plasma 6.5.0. If you still see the same bug in that version of > Plasma, when it becomes available on your system, feel free to reopen this > bug. Thanks! I have the same issue on 6.4.5 on Fedora Kde Plasma. I have Spectacle configured to automatically copy the image to my clipboard when I press the print-screen key. However, I should note that it happens randomly, sometimes it automatically copies the image over to my clipboard without issues, and sometimes it copies just an empty image. If it copies an empty image I have to click the "copy to clipboard" button on the spectacle window.
I am having the same issue on Arch Linux running Plasma 6.4.5 (and Spectacle 6.4.5) with Frameworks 6.18.0. In my case, choosing the "Copy" option while in the snipping mode copies an empty object. There's a blank clipboard entry in the clipboard widget. Same issue arises when I choose the "Save" option with "Copy image to clipboard" after taking a screenshot setting enabled. If I choose "Accept", which leaves the snipping screen and opens a new window with the screenshot, and choose "Copy" from that window, it does get copied into the clipboard. This issue seems to only affect cases where I don't move onto the after-screenshot window.
I can confirm this has still been happening since reporting daily. Sometimes it gets copied, sometimes the clipboard item is empty. Forcing (manually) by copy to clipboard works. Operating System: KDE neon User Edition KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2 Kernel Version: 6.14.0-33-generic (64-bit) Graphics Platform: Wayland
As I had said in an earlier comment, this is fixed in Plasma 6.5.0. Unfortunately, the bug will still be present in 6.4.5. Please only reopen this bug if you can reproduce it when your system is running Plasma 6.5.0.
(In reply to TraceyC from comment #11) > As I had said in an earlier comment, this is fixed in Plasma 6.5.0. > Unfortunately, the bug will still be present in 6.4.5. > > Please only reopen this bug if you can reproduce it when your system is > running Plasma 6.5.0. I'm on 6.5.1 and am getting the exact same bug and behavior.
(In reply to D Mitsuki from comment #12) > (In reply to TraceyC from comment #11) > > As I had said in an earlier comment, this is fixed in Plasma 6.5.0. > > Unfortunately, the bug will still be present in 6.4.5. > > > > Please only reopen this bug if you can reproduce it when your system is > > running Plasma 6.5.0. > > I'm on 6.5.1 and am getting the exact same bug and behavior. I am on 6.5.2 and getting the same behavior.
*** Bug 511637 has been marked as a duplicate of this bug. ***
After switching to kde plasma 6.5.2 on fedora the error kept happening for me however I was able to circumvent the issue. Currently the "print screen" key is set to catching a rectangular area in my shortcuts, and now spectacle always correctly copies the screenshot area to my clipboard.
6.5.4 i still have this issue, after a system restart the first time I try to copy an image using spectacle, I get the empty history row. If I re-open spectacle and copy again, it works. From then on until I do a system restart it won't happen for me again. same behaviour when I did kquitapp5 klipper and systemctl --user restart plasma-plasmashell.service instead of system restarts
(In reply to Leah from comment #16) > 6.5.4 i still have this issue, > after a system restart the first time I try to copy an image using > spectacle, I get the empty history row. If I re-open spectacle and copy > again, it works. From then on until I do a system restart it won't happen > for me again. > > same behaviour when I did kquitapp5 klipper and systemctl --user restart > plasma-plasmashell.service instead of system restarts 6.5.3, my bad
Been also running into this issue on EndeavorOS (Arch Linux) for a few versions now. Currently running Plasma 6.5.3 I've done some surface level debugging using WAYLAND_DEBUG=1 and managed to compare a successful copy and a failed copy. It seems that the image copy flow gets interrupted by the selection getting set to nil. Successful copy: ------------------------- [...] [2520665.344] {Default Queue} ext_data_control_offer_v1#4278190087.offer("image/webp") [2520665.346] {Default Queue} ext_data_control_offer_v1#4278190087.offer("image/xbm") [2520665.348] {Default Queue} ext_data_control_offer_v1#4278190087.offer("image/xpm") [2520665.350] {Default Queue} ext_data_control_device_v1#49.selection(ext_data_control_offer_v1#4278190087) [2520665.353] {Default Queue} -> ext_data_control_offer_v1#4278190083.destroy() [2520665.358] {Default Queue} wl_callback#67.done(167492) [2520666.050] {Default Queue} wl_data_source#77.send("application/x-qt-image", fd 32) [2520670.153] {Default Queue} wl_data_source#77.send("application/x-qt-image", fd 37) [...] ------------------------- Failed copy: ------------------------- [...] [3038509.436] {Default Queue} ext_data_control_offer_v1#4278190087.offer("image/webp") [3038509.437] {Default Queue} ext_data_control_offer_v1#4278190087.offer("image/xbm") [3038509.439] {Default Queue} ext_data_control_offer_v1#4278190087.offer("image/xpm") [3038509.440] {Default Queue} ext_data_control_device_v1#49.selection(ext_data_control_offer_v1#4278190087) [3038509.442] {Default Queue} -> ext_data_control_offer_v1#4278190083.destroy() [3038509.446] {Default Queue} wl_data_device#13.selection(nil) [3038509.447] {Default Queue} -> wl_data_offer#4278190086.destroy() [3038509.450] {Default Queue} ext_data_control_device_v1#49.selection(nil) [3038509.452] {Default Queue} -> ext_data_control_offer_v1#4278190087.destroy() [3038509.455] {Default Queue} wl_data_source#65.cancelled() [3038509.457] {Default Queue} -> wl_data_source#65.destroy() [3038509.459] {Default Queue} wl_callback#66.done(154796) [...] ------------------------- I've managed to reproduce the issue with Spectacle launched from command line, launched via PrtScr, and copies failed both when pressing Ctrl+C in Spectacle and when clicking on the copy button. Is there some way to monitor all Wayland messages sent and received by KWin?
Still happening on 6.5.3 on cachyOS, but this is not isolated to spectacle for me once the bug is triggered. Pastes usually work for a while, then fail for everything; vven copying from one firefox tab into another will exhibit this empty paste. Once it happens I can still copy and paste within a kolourpaint or gimp window, but trying to paste the same selection into anything else will fail.
Hi all, I believe I have a way to make this reproducible: I noticed that after ~10 or so seconds is when I consistently fail to paste an image. When I paste before that time frame it succeeds.
(In reply to Keith Santamaria from comment #20) > Hi all, > > I believe I have a way to make this reproducible: I noticed that after ~10 > or so seconds is when I consistently fail to paste an image. When I paste > before that time frame it succeeds. It happens to me even if I paste before, so I can not confirm this specific ~10 second behavior.
I am able to reproduce this easily with the following steps: 1. Rectangular region screenshot (not tested with other types) 2. Move to a different virtual desktop 3. Release the hotkeys for moving desktops 4. Move to another virtual desktop for pasting 5. Try pasting with hotkeys Note 1: Step 3 is crucial to make this easy to reproduce. *However*, I have been able to reproduce without it, it's just much harder. Note 2: The virtual desktop you paste in can be the same as the one you made the screenshot in, but it's essential that you switch to another and back. I've not been able to reproduce the bug without the virtual desktop switches. In case it matters, my hotkeys are: Move desktop: ctrl+alt+<arrows> Paste: ctrl+v KDE Plasma: 6.5.4 KDE Frameworks: 6.20
After some more testing, it seems to me that if you switch via an *empty virtual desktop* then the bug triggers. 1. Rectangular region screenshot (not tested with other types) 2. Switch to empty virtual desktop (unless the first one is empty, then that's sufficient) 3. Try pasting with hotkey
Sorry for the spam, but I keep refining how to reproduce this (and I cannot see a way to edit my comments?). It seems that a slight pause after taking the screenshot is necessary (or at least makes it much easier) to reproduce: 1. Rectangular region screenshot (not tested with other types) 2. Slight pause (0.5s-1s) 3. Switch to empty virtual desktop (unnecessary if the virtual desktop where you took the screenshot is itself empty) 4. Switch to virtual desktop where you want to paste 5. Try pasting with hotkey The desktop switches you can do as fast as you'd like, but adding the slight pause in step 2 is crucial in triggering the bug. If you switch desktops immediately after taking the screenshot then you might not be able to reproduce. I have 3x5 virtual desktops (row x cols) in case that matters.
I've done some more debugging, specifically with KDEs debug console (qdbus org.kde.KWin /KWin showDebugConsole): What seems to happen is: Buggy path: 1. Spectacle sets the clipboard contents 1.1. Clipboard shows "data control by /usr/bin/spectacle" 2. ~0.3s passes since screenshot 3. Klipper (plasmashell) takes over the clipboard contents to prevent it from being wiped when spectacle closes 3.1. Clipboard shows "data control by /usr/bin/plasmashell" 4. Clipboard is wiped upon changing to an empty virtual desktop Non-buggy path: 1. Spectacle sets the clipboard contents 1.1. Clipboard shows "data control by /usr/bin/spectacle" 2. Switch virtual desktop 3. ~0.3s passes since screenshot 4. Klipper (plasmashell) takes over the clipboard contents to prevent it from being wiped when spectacle closes 4.1. Clipboard shows "data control by wl_data_source@<x> of /usr/bin/plasmashell" 5. Clipboard is *not* wiped upon changing virtual desktops Note the difference in 3.1 and 4.1 ("data control by /usr/bin/plasmashell" vs "data control by wl_data_source@<x> of /usr/bin/plasmashell"). I assume when the "~0.3s" has passed is when Spectacle exits, triggering Klipper to take over the clipboard contents, and that how Klipper does that somehow depends on whether the virtual desktop has changed or not.
An important clarification in the "non-buggy path": 2. Switch virtual desktop -> 2. Switch to an *empty* virtual desktop
Even easier to reproduce: Screenshot on a non-empty virtual desktop, wait >0.3s, and then open the application launcher ("windows key"). That clears the clipboard. It seems to me that the "application/x-kde-onlyReplaceEmpty" MIME type is relevant here. If it's set to empty string (or whitespace, not sure which), then opening the application launcher (or making sure there's no active window (which is what switching to a virtual desktop did, I think)), then the clipboard is cleared. However, if one avoids the bug by making sure there's no active window before the 0.3s, then "application/x-kde-onlyReplaceEmpty" is set to "1". When it's set to "1" I can never reproduce the bug. I can only find the value/MIME type being explicitly set in this function: https://invent.kde.org/cwo/plasma-workspace/-/blob/d0069721c8152fe7e92b38d4e032ebd8846461d0/klipper/systemclipboard.cpp#L119, and there the "1" is hardcoded.
I reported the bug and I don't use virtual desktops, so they are irrelevant. Thanks for debugging deeper though!
(In reply to Daniel Duris from comment #28) > I reported the bug and I don't use virtual desktops, so they are irrelevant. > Thanks for debugging deeper though! I don't think virtual desktops are required to reproduce after all, they were just necessary in the first method I discovered. > Screenshot on a non-empty virtual desktop, wait >0.3s, and then open the application launcher ("windows key"). That clears the clipboard. Maybe you can try this? If you view the clipboard contents via `qdbus org.kde.KWin /KWin showDebugConsole` you should be able to see when the clipboard is cleared.
Git commit b71af4e1afcf72b8c9da315dc8d728db70d753c0 by David Edmundson, on behalf of David Redondo. Committed on 15/12/2025 at 10:16. Pushed by davidedmundson into branch 'master'. ksystemclipboard: Dispatch read events in another thread WaylandClipboard wraps ext_data_control if an application tried to read the clipboard using QClipboard whilst it owns the data control we would deadlock. This was previously being solved by trying to transfer mimedata to the regular clipboard upon gaining focus. However this never worked reliably and efforts to fix this only made it more complicated. To solve the original deadlock all ext_data_control classes now live on another thread which dispatches events on a separate queue. A recursive mutex allows the main thread to read mimedata and no wayland events which change the mimedata process until this is complete. Related: bug 480448, bug 496029, bug 502831, bug 505281, bug 506467, bug 509065, bug 509689, bug 511736 FIXED-IN: 6.22 M +116 -14 src/systemclipboard/waylandclipboard.cpp M +3 -0 src/systemclipboard/waylandclipboard_p.h https://invent.kde.org/frameworks/kguiaddons/-/commit/b71af4e1afcf72b8c9da315dc8d728db70d753c0
Thanks for the update and fix, David (x2)! I can no longer reproduce the bug. However, the commit you referenced is not the one that fixed what I've been seeing, but this commit did: https://invent.kde.org/frameworks/kguiaddons/-/commit/b752bfdcb44464db66dc5a8001b4eb784de4eafb
The issue haven't been fixed after update Frameworks to 6.22 Operating System: EndeavourOS KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.4-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics Memory: 32 GiB of RAM (30,7 GiB usable) Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: MINIPC PN52
It seems like i face this only in my main account and only clear desktop screenshot gives me blank element in clipboard new account almost everything seems to be fine
Reporter here. The bug seems to have been fixed. I'll observe for another couple of days. KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.14.0-37-generic (64-bit) Graphics Platform: Wayland