SUMMARY Occasionally when taking a screenshot in Spectacle will fail to copy the image to the clipboard. I see it appear in clipboard history but I'm unable to paste it anywhere with Ctrl+V. Other programs that read from the clipboard (GiMP) also cannot see the image data, and any attempt to re-copy it by clicking the entry in the clipboard history fails. STEPS TO REPRODUCE 1. Launch spectacle and take a screenshot of any region of your screen 2. Attempt to paste into a Dolphin window (Crl+V), or in GiMP press Ctrl+Shift+V 3. Repeat until the error occurs OBSERVED RESULT Both Dolphin and GiMP report that the clipboard is empty. EXPECTED RESULT Dolphin should display a prompt to name the file and GiMP should load and display the image. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Since the attachment file size limit is only 4MB, here is a video of the bug uploaded to youtube: https://www.youtube.com/watch?v=3bXx0_t1K-c
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/182
A possibly relevant merge request was started @ https://invent.kde.org/plasma/spectacle/-/merge_requests/481
I also have this issue, and it is so frequent that I have been able to paste a screenshot only a handful of times total over the past 2-3 days (mainly in the form of trying to post screenshots to Discord). The 3rd-party Flameshot software does not have the issue, but I prefer Spectacle's UX when the bug is not occurring. Software Versions: Fedora 42 KDE Edition Plasma 6.5.1 Spectacle 6.5.1 Frameworks 6.19.0 Qt 6.9.3
*** Bug 511736 has been marked as a duplicate of this bug. ***
I'm not completely certain, but this might be a duplicate of an earlier closed bug, which has now been re-opened: 507792
*** Bug 512029 has been marked as a duplicate of this bug. ***
I have seen this in the recent past: When I have Spectacle set up automatically copy to the clipboard, the screenshot would fail to paste into any app. When I manually clicked "Copy to clipboard" then the thing that's added to the clipboard will paste into apps. However I can't reproduce the issue on current git master of Spectacle and KWin right now.
I can't reproduce the issue depicted in the video with today's git master, but it looks like Spectacle's settings (and also system notifications?) have been customized. Sollace, can you describe the specific settings you're using?
Is this a dupe of https://bugs.kde.org/show_bug.cgi?id=480448
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/191
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 507792, 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
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
There may be an old value in either the clipboard or Spectacle configuration files that's interfering. Try backing up and then removing these two files in your regular user account $HOME/.config/spectaclerc $HOME/.config/klipperrc Then, log out and back in. Do you still experience the bug after removing those files?
Same behaviour here. I take the screenshot, I paste with ctrl+v, nothing happens, I check my clipboard history (in CopyQ) and I see the screenshot, if I paste from CopyQ, it pastes as expected, and subsequent normal pastes (eg pressing ctrl+v) will paste the screenshot as expected. Still seems like something empties the clipboard after storing the screenshot there.
Reopening, since the bug is still happening with Frameworks 6.22
Setting back to confirmed
*** Bug 506467 has been marked as a duplicate of this bug. ***
*** Bug 512178 has been marked as a duplicate of this bug. ***
*** Bug 484907 has been marked as a duplicate of this bug. ***
*** Bug 512163 has been marked as a duplicate of this bug. ***
*** Bug 511179 has been marked as a duplicate of this bug. ***
*** Bug 500042 has been marked as a duplicate of this bug. ***
As 512178 was closed as a duplicate, I will attach my logs here also. As above, rectangular regions fail to copy to clipboard sometimes. Though I note that the data is "there" most of the time (ie, I can see an image preview in clipboard history), it is not pastable to most apps. I can paste it to https://www.paste.photos/, recopy it from there and it works fine. Logs 1: journalctl -b | grep clipboard "Jan 03 20:59:14 [Hostname] plasmashell[1059]: qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:16:15: QML QQuickItem (parent or ancestor of QQuickDragAttached): Binding loop detected for property "active": qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:19:9" Logs 2: journalctl -b | grep clipboard qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:16:15: QML QQuickItem (parent or ancestor of QQuickDragAttached): Binding loop detected for property "active": qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:19:9 Feb 02 20:52:59 ArchPad plasmashell[1060]: qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:16:15: QML QQuickItem (parent or ancestor of QQuickDragAttached): Binding loop detected for property "active": qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:19:9 Feb 04 17:24:25 ArchPad kscreenlocker_greet[393181]: Data set on unsupported clipboard mode. QMimeData object will be deleted. Feb 04 18:28:39 ArchPad plasmashell[1060]: qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:26:9: QML Image: Error decoding: file:///home/smathles/.local/share/klipper/data/da39a3ee5e6b4b0d3255bfef95601890afd80709/da39a3ee5e6b4b0d3255bfef95601890afd80709: Unsupported image format Feb 04 18:29:11 ArchPad plasmashell[1060]: qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:26:9: QML Image: Error decoding: file:///home/smathles/.local/share/klipper/data/da39a3ee5e6b4b0d3255bfef95601890afd80709/da39a3ee5e6b4b0d3255bfef95601890afd80709: Unsupported image format Feb 04 18:29:37 ArchPad plasmashell[1060]: qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:16:15: QML QQuickItem (parent or ancestor of QQuickDragAttached): Binding loop detected for property "active": qrc:/qt/qml/org/kde/plasma/private/clipboard/ImageItemDelegate.qml:19:9 The last log is actually 2 days of bugs. The second was worse than the first (no image copied at all).
Testing this again on Plasma 6.5.5: Oddly enough it appears to work correctly when taking screenshots of small regions of the screen (when the system is not under load), but if I select a larger region like (near or close to) an entire desktop it fails to copy. This makes me think that the issue is related to the amount of time (or amount of data?) it takes to copy the image to the clipboard. In fact, it works for any region smaller than the size of my monitor, but if I select almost exactly the full monitor it fails to copy.
Can confirm that selecting the whole screen seems to always fail. I use a 4K screen.
I'd been experiencing this issue for quite awhile on KDE, probably the majority of the time I was trying to take screenshots using Spectacle. A week or so ago I came across this report and followed TraceyC's advice of removing the Spectacle configuration file (I didn't have a clipboard one), and that's improved things significantly. I now have Sollace's issue of screenshots still being somewhat unreliable when taking them of the whole screen or of multiple monitors, whereas smaller screenshots are working all the time as far as I can tell.
I spent another 2 days hunting this down, and by now I'm confident enough to say it's not a spectacle bug. It's a bug at the intersection of system QT, plasmashell(plasma-workspace), and possibly kwin when dealing with the ownership of large images in the clipboard after application exit (I tested using around 4k resolution). All testing was done on plasma 6.6.1/frameworks 6.23. For spectacle in particular, I do a rectangle screenshot of most (but not all) of my two adjacent 1440p screens. Spectacle is, of course, set to close after the rectangle screenshot is taken. I have also tested spectacle in particular on a fresh user account, with the same results. Aside: Running ```qdbus6 org.kde.KWin /KWin showDebugConsole``` with the Clipboard tab open visualizes what is going on well (and, by merrit of slowing down my system, possibly makes the issue occur consistently). Occasional symptom: ```spectacle[41838]: Failed to send all clipobard data; sent -1 bytes out of 939987``` Here are the reasons: 1) By disabling plasmashell's klipper (which you do in the System Tray settings by setting the Clipboard icon to "Never (disable)") and using https://github.com/Linus789/wl-clip-persist (which works for my use case), the issue is gone. 2) Other native QT applications (kolourpaint, krita) have the same issue of the clipboard contents disappearing after they are closed. (Krita was tested as the prealpha appimage, with wayland QPA, bundeled QT 6.8, using "Copy merged" instead of the regular Copy) 3) GTK applications (firefox, gnome "drawing") are fine, flatpak or no. 4) QT applications inside flatpak are FINE (presumably because they use the desktop portal to hand over the clipboard data). I don't really have a solid enough understanding of wayland/kwin/plasma to pin down where exactly things go wrong, so I'd appreciate it if somebody could take over the task of figuring that out and making a comprehensive report at the right place! Feel free to link this comment. As another tangent, I don't really understand what exactly is going in with regard to the image formats in the clipboard. The KWin debug console makes it seem like images are converted into 20 different formats, possibly lazily, and the debug console itself is what triggers the actual conversion to occur? I'm also reasonably sure that image data is being transfered and stored completely uncompressed, which breaks down rather splendidly when you go to image sizes of 30000*3000 (long hangs, presumably over pipe communication, clipboard manager taking over a GB of memory), but that may be a wayland protocol issue, IDK.
(In reply to Simon Ra from comment #29) > I'm also reasonably sure that image data is being transfered and > stored completely uncompressed, which breaks down rather splendidly when you > go to image sizes of 30000*3000 (long hangs, presumably over pipe > communication, clipboard manager taking over a GB of memory), but that may > be a wayland protocol issue, IDK. Interesting that you bring that up because I've noticed as well that (when it works) images have taken extremely long to transfer from the clipboard to other applications. Particularly when pasting a large screenshot (i.e. of a running game) into discord, discord is seemingly aware that a file was pasted into it but the actual contents of the image doesn't appear in the preview for maybe 15s to 1 minute if it does at all.
Looks like another reason to stay away from Wayland, I am not seeing this issue with x11.
KDE 6.6.3, KDE Framework 6.24.0, QT 6.10.2. Having the same issue with big enough screenshots in specific applications, usually games. Factorio screenshots consistently fail to copy. In previous KDE versions Factorio screenshots at least showed up in the clipboard history, simply choosing any other entry from the history and then choosing back the screenshot worked well. However, in the current version the screenshot appears to be an empty entry, basically making the game non-screenshottable. I'm only aware of Factorio as an reproducible environment.
Copying this over from my comment in 510575 since this one seems more active & related. I'm also getting this, quite badly, using the shortcut "Capture Rectangular Region" which I have bound to "Ctrl+Del" I can usually screenshot a smaller section of my screen 60-70% of the time, but if I try to screenshot say half the screen or more it fails 90% of the time, ending up with an empty clipboard entry. However I've noticed if I use the shortcut for just "Launch" ("Meta+Shift+S") I can screenshot the entire screen and it will open up with the "unsaved" window after that let's you edit/save/etc, and it automatically copies into the clipboard successfully. Up until recently I had to screenshot something then open the clipboard, copy something else then recopy the screenshot to get it to paste most of the time. Specs/etc: 3 Screens [1440p / 1440p / 1080p] Operating System: Bazzite 43 KDE Plasma Version: 6.6.2 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 Kernel Version: 6.17.7-ba28.fc43.x86_64 (64-bit) Graphics Platform: Wayland Processors: 24 × 13th Gen Intel® Core™ i7-13700K Memory: 48 GiB of RAM (46.7 GiB usable) Graphics Processor 1: AMD Radeon RX 9070 XT Graphics Processor 2: Intel® Graphics Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7D91 System Version: 2.0 Spectacle --version: 6.6.2
I'm not sure the image size is the culprit, as I've had screenshots fail to copy that were relatively small (roughly 1000 x 500, IIRC).
Image size is definitely NOT the culprit. I was taking lots of small screenshots during a presentation and even the smallest images (600x400) would repeatedly (and maddeningly) fail to copy to the clipboard. KDE Plasma Version: 6.5.2 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Graphics Platform: Wayland
My current understanding of this is that while there is a bug somewhere in klipper that can abort the clipboard ownership transfer that occurrs when closing the application that copied it "to the clipboard" (the data really lives in the wayland client process until it closes, at which point this transfer happens). Since at least in my testing this only happens if the source application is using QT and destination is plasmashell/klipper, I'd speculate that an implementation difference in qt-wayland-client compared to other clients triggers this behaviour. As it works for me if I replace klipper, likely the bug needs to be fixed there. However, there is a larger issue if you look at what happens during such a transfer: klipper (or another way to persist a wayland clipboard) has to copy *every MIME type offered* by the client. And it has no way of knowing what the actual content original MIME type of the clipboard was. Someone (I suspect the wayland clients, because I can't find any mention of MIME type conversions in kwin) is offering to convert whatever actual format the data is in to about every format under the moon, on demand. This means converting e.g. something that's originally a PNG into about 30 formats, some of which are uncompressed and have a huge memory footprint, and then transfering that to klipper. Not ideal for large images, memory usage, or not hanging the system. If I'm right, this could be ugly to fix, because presumably this offering of many MIME types is part of a wayland protocol. So it would involve updating the protocol. A clumy first draft would be saving the "original/primary" MIME types in a special MIME type like "wayland/original-mime-types" or somesuch, if the MIME conversion at that level is desired/needed. personally I question the use case of offering "best-effort" conversions, because really, how often do you need a 10000x10000 .ico file? A png of the first frame of an animated gif? Risk degraded alpha channels? A png to give the illusion of having made the original jpeg lossless? Are you okay losing image metadata because you took the bmp over the png? However, changes on that level will likely take forever. Maybe kwin is somehow in a position to set an equivalent "x-kde/original-mime-types", but I kind of doubt it has the required information? And if not the clients (of which there are many) would have to implement it. And obviously the clipboard persistors would have to implement it either way. (In reply to Dan Dascalescu from comment #35) > Image size is definitely NOT the culprit. I was taking lots of small > screenshots during a presentation and even the smallest images (600x400) > would repeatedly (and maddeningly) fail to copy to the clipboard. While it's likely not the cause per se, it's a good trigger to reproduce it for me, because there is more data to shovel over. Meaning a 10x10 image has never failed to copy for me, while something absurdly large will trigger it 100% of the time with the kwin debug window open.
(In reply to Dan Dascalescu from comment #35) > Image size is definitely NOT the culprit. I was taking lots of small > screenshots during a presentation and even the smallest images (600x400) > would repeatedly (and maddeningly) fail to copy to the clipboard. > > KDE Plasma Version: 6.5.2 > KDE Frameworks Version: 6.19.0 > Qt Version: 6.9.2 > Graphics Platform: Wayland Note that you're using somewhat old versions. Frameworks 6.23 contained numerous clipboard fixes, and a few more went into 6.24 and 6.25. If you have the ability to upgrade your system, I'd recommend it.
*** Bug 519088 has been marked as a duplicate of this bug. ***
The latest report of this in the duplicate is on Plasma 6.6.4 Linux/KDE Plasma: EndeavourOS KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.11.0
A possibly relevant merge request was started @ https://invent.kde.org/plasma/spectacle/-/merge_requests/536
Should be fully fixed by David Edmundson with https://invent.kde.org/plasma/spectacle/-/commit/bd92669ed96fb203d18d5c277f0373a2ce5f6c2a, landing in Plasma 6.6.5. Sollace or anyone else still experiencing *the exact same issue originally reported here* after upgrading to Plasma 6.6.5, feel free to re-open the bug report. If anyone still experiences different issues after upgrading to Plasma 6.6.5, please open new bug reports about those issues. Thanks!