SUMMARY I've had the 'Keep the selection and clipboard the same' option selected in my clipboard configuration for many years, but just today I observed that it's stopping me from copy&pasting multicell data between two sheets of the same LibreOffice Calc file (copy&pasting only one cell works fine). This is a new bug, as I've always been able to do the described operation. Interestingly, I can paste the copied data into the same sheet, and also into another Calc file. It's only another sheet of the same file that I can't paste the data into. STEPS TO REPRODUCE 1. Select 'Keep the selection and clipboard the same' in the clipboard configuration. 2. Open a LibreOffice Calc file with multiple sheets. 3. Go to one of the sheets, select multiple cells and copy (Ctrl+C, or click on the 'copy' icon). 4. Go to another sheet of the same file, and try to paste the copied data (again, with Ctrl+V or the 'paste' icon). Nothing happens. 5. Now go to the same sheet you copied the data from, or to another Calc file, and try to paste. It works. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20250602 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.15.0-1-default (64-bit) Graphics Platform: Wayland LibreOffice: 25.2.3.2 ADDITIONAL INFORMATION I've seen this bug in another person's computer too (running Kubuntu, while mine is Tumbleweed), so I'd say it can be reproduced by anyone.
I can confirm this very strange bug exactly as described. Perhaps related: If I open the history view, click on another item to make it the active one, click on the copied cell data to make it active again, and then Ctrl+V paste into Calc, an *image* containing a depiction of the copied cells is pasted.
Reminds me of https://invent.kde.org/plasma/kwin/-/merge_requests/6339
The bug is still present in an updated system: Operating System: openSUSE Tumbleweed 20250905 KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.2 Kernel Version: 6.16.3-1-default (64-bit) LibreOffice: 25.8.1.1
BTW, I removed "wayland-only" from the keyword list, since it happens in X11 as well.
Fixed by Fushan Wen with https://invent.kde.org/plasma/plasma-workspace/-/commit/abc5b7fdf82addfb042c49b47b0f7b942511fb42 in Plasma 6.4.6!
*** Bug 510560 has been marked as a duplicate of this bug. ***
I believe this may have been incorrectly reported as fixed, since I just installed Plasma 6.5.0 and it is still present (both the reported bug and Nate's observation in comment 1). To check it, please have in mind that 'Keep the selection and clipboard the same' must be activated in the clipboard configuration to see the bug. Besides, there's something I've just observed that may explain why this was thought to be fixed. If you copy the multicell data, then create a new sheet and paste it, it works fine! That is, in order to see the bug, the sheet where you want to paste the copied cells must have been created beforehand. It's really strange...
Darn, I guess I tested incorrectly.
This is still present in: Operating System: openSUSE Tumbleweed 20251124 KDE Plasma Version: 6.5.3 KDE Frameworks Version: 6.20.0 Qt Version: 6.10.0 Kernel Version: 6.17.8-2-default (64-bit) Graphics Platform: Wayland Just to be clear: both bugs observed in this report are still present: 1. The fact that you can't copy+paste multicell data between different Calc sheets. 2. The fact that, after clicking on the copied data in the clipboard, it pastes as an image. This initially seemed like it could have been solved by Fushan Wen's fix to Bug 504470, but it actually wasn't.
This bug is still present in Plasma 6.6: Operating System: openSUSE Tumbleweed 20260216 KDE Plasma Version: 6.6.0 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 Kernel Version: 6.18.9-1-default (64-bit) Graphics Platform: Wayland
The problem is Klipper doesn't preserve LibreOffice's application data. Currently it only preserves "text/*", "application/json", "application/xml" But LibreOffice Calc uses formats like application/vnd.oasis.opendocument.spreadsheet for multicell data. The question is whether Klipper should preserve them.
>The question is whether Klipper should preserve them. The more we try to do, the more we break. >ve had the 'Keep the selection and clipboard the same' o https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6460 This is the only option.
This shows the flaw of the feature. To make it work 100% like one expect we would need to mirror all data every time.
I created an MR solving the titular bug. For the secondary bug, where selecting an older entry coming from Libreoffice results in pasting an image, I am a bit stuck. Klipper now only basically allows storing images and text in history, because of this MR: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5315 Libreoffice sends a bunch (like 20) different formats - lots of internal ones, a PNG image and some text. The internal ones are dropped when saving to history so we get the image. When we select the entry in history, it offers the image to libre office in addition to plain text. LO than prefers the image. BTW pasting into a browser (Vivaldi on my end, based on Chromium) also pastes an image. constexpr std::array<QStringView, 3> s_acceptableTextFormatPrefixes{ u"text/", u"application/json", u"application/xml", }; I tried adding u"application/x-openoffice-", u"application/x-libreoffice-", to these to see if it would be a quick and dirty trick to fix this, but that did not result in the LO-native types being added. Not sure yet where it gets blocked in the code. Anyway, a proper architecture would probably be to always store the first offered format (as per https://doc.qt.io/qt-6/qmimedata.html#formats it is the priority one) and then text. It is unclear to me whether image data should be stored in such a case too - in case of Libreoffice, probably not, but in case of let's say GIMP, we would want to store a png or something in addition to xcf, which nothing else understands. Because this bug needs to be kept in mind: https://bugs.kde.org/show_bug.cgi?id=504469 A possible solution might be to not store images when there is text, but I kind of think that might break a bunch of graphical apps that maybe also send text alongside image data?
Hm, that part about adding u"application/x-openoffice-" to whitelist not working is not right. I must have mungled something, now it works. But that clearly is not a systematic fix.
Not sure why bugzilla did not pick up the MR, here it is: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6956
Git commit a66825f521466c469280b250553207e55a03e40a by Tomáš Hnyk. Committed on 20/08/2026 at 05:42. Pushed by ngraham into branch 'master'. Klipper: Mark sync selection consistently Previously, the flag was not applied consistently, which was breaking for example LibreOffice Calc when copying between sheets. To fix this, only the change to systemclipboard.cpp is needed, the change to hisotrymodel.cpp is just for correctness sake. There, the code only fires when "Keep the selection and clipboard the same" is checked, the reason for clipboard update is always SyncSelection, so we should pass it on. FIXED-IN: 6.8.0 M +3 -1 klipper/historymodel.cpp M +3 -0 klipper/systemclipboard.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/a66825f521466c469280b250553207e55a03e40a
*** Bug 524503 has been marked as a duplicate of this bug. ***
(In reply to tomashnyk from comment #14) > I created an MR solving the titular bug. Thank you very much for your work