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.