SUMMARY Copy paste of images is working in strange way. Very often I cannot paste images between the apps, or I must do it twice (first time doesn't paste anything). I know already from another bug report that Gimp related cases are Gimp fault, but Libre Office, Firefox, Edge, Chrome are also broken? I've never seen such issues in other desktop environments. I suspect it's something related to copy paste between GTK -> QT apps. Could you please help me to provide enough information for You to solve it to create reproducible case? My tries are: STEPS TO REPRODUCE 1. Run "spectacle -rbc", try to paste in Firefox or Edge in any webapp, sometimes it's working sometimes path is pasted or nothing. 2. Open Gimp, copy image try to paste in LibreOffice, sometimes contents of image is pasted. 3. When copying image from Dolphin in browser only image path is pasted sometimes in browser window. On second try it's working. OBSERVED RESULT Images are not copied, or only paths are pasted, or file content is pasted. Worst thing it occurs randomly and sometimes it's working. EXPECTED RESULT It should paste image. SOFTWARE/OS VERSIONS KDE Neon: 21.04 (but problems was also in previous versions)
All of these use cases are working for me. Can you do the following? 1. Open the Clipboard applet in your System Tray and click the "Pin" button in the corner. 2. Copy the image in the manner you expect If you copy an image and an image appear in the clipboard, or if you copy a file and a path appears in the clipboard or a file entry appears in the clipboard, then our system is working properly and the bug is in how the app you're pasting it into is interpreting the paste data.
Thanks, I'll check that.
I've created screenshot with "spectacle -rbc". Image is showing under clipboard icon, but paste is no working anywhere (tried Firefox, Gimp, Edge, KolourPaint). After I clicked in clipboard element on list now I can paste. I've created second screenshot. Now I was able to paste, but only once. I think the issue is here that after some typing on keyboard clipboard content is lost. Also I've I remembered in meantime about very annoying issue that after pressing ctrl+c without selecting anything clipboard content is lost. It is intentional?
Very interesting. So the image data gets into the clipboard but is somehow not active until you click on it. *Before* you click on it, it is the top item, or the second item? Also, is this happening on X11 or Wayland?
Created attachment 138424 [details] Example of notification
It's second item like on attachment. I've tried to reproduce it and as I can see now that new row is showing when I type something in browser's window for example in Gmail.
Do see the image in the clipboard applet, though?
Yes, there are duplicated entries there, one with image, but other with only notification text.
Can you send a screenshot of what the Clipboard applet looks like?
Created attachment 138522 [details] example clipboard
The top entry in your latest screenshot is a file, not a pixmap from an image. What did you do to get that there? When I do `spectacle -rbc` I get a pixmap entry which can be pasted into apps that accept pixmap clipboard data.
It was spectacle -rbc, it always show two entries as I'm checking now. In Messenger web app ctrl+v pastes two images instead of one what is really strange also. I've discovered that I had unchecked option "Ignore selection" which probably was fault of disappearing items from clipboard.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I've provided info
I might be hijacking this report and it might be a different problem, but it looks the same. I just analyzed a LibreOffice image pasting bug on Wayland in https://bugs.documentfoundation.org/show_bug.cgi?id=142889 Repo: 1. spectacle -> copy to clipboard 2. "wl-paste -l" lists "image/png" 3. "wl-paste -t image/png >/tmp/unknown.data" 4. "hexdump -C /tmp/unknown.data | head -n 1" 00000000 42 4d 36 ec 5e 00 00 00 00 00 36 00 00 00 28 00 |BM6.^.....6...(.| So instead of ~375k PNG, which I get from spectacle on save, I got a 6.2m BMP from the clipboard, which LO's PNG reader doesn't like :-( That's for my freshly updated Debian Bullseye, which has some KDE 5.20.5 variant.
Jan-Marek, that specific issue appears to be caused by a Qt bug, which KDE developer Jan Pontaoski has helpfully fixed already in https://codereview.qt-project.org/c/qt/qtwayland/+/366769. The fix will be backported into the KDE patch collection for Qt 5.15.
(In reply to Nate Graham from comment #16) > Jan-Marek, that specific issue appears to be caused by a Qt bug, which KDE > developer Jan Pontaoski has helpfully fixed already in > https://codereview.qt-project.org/c/qt/qtwayland/+/366769. The fix will be > backported into the KDE patch collection for Qt 5.15. Thanks for the quick reply. Very much looks like my LO bug. Now I just need to tell Debian to fix a non-security bug in QtWayland; it is really nasty... (I could use a QImage to catch the "application/x-qt-image" type and use convertToFormat to get the right stuff, but this feels like a horrible workaround :-( ... still tempting, but then other non-qt apps will still fail. So guess I'll just wait for a fixed Qt5)