SUMMARY This bug occurs when user is trying to paste primary clipboard from non-Qt app to Qt one. Lets say there are two apps opened: KWrite and Meld. The user is working in KWrite, while Meld is located on the side. The user is then trying to select text from Meld and paste it in KWrite with middle click or shortcut (CTRL+SHIFT+INS default). It will work on the first occasion, but on the second occasion apps like Meld and Cherrytree will reject selection. Simply, if user starts to drag pointer for purpose of selecting text, no selection will occur. It will be skipped/rejected by the app. If user then try to paste in KWrite, secondary clipboard will be pasted. On the other side, if instead of Meld user is trying to use LibreOffice Writer, on second occasion selecting text will be accepted by Writer, but when trying to paste the primary clipboard to KWrite, secondary clipboard will be pasted instead. It appears that every second paste malfunction. These bugs do not occur when user double-click to select a word. Furthermore, everything works fine if user, while working on KWrite, first click on Meld/Writer, thus make it active, and then starts to drag a cursor to select text. STEPS TO REPRODUCE with Meld 1. Ensure the secondary clipboard contains some text 2. Open KWrite and Meld side by side 3. From KWrite directly click on Meld and drag cursor to select text 4. Paste primary clipboard to KWrite 5. Repeat 3. and 4. OBSERVED RESULT There will be no text selected within Meld on second occasion, but only secondary clipboard can be pasted in KWrite. EXPECTED RESULT There should be text selected within Meld on second occasion, but primary clipboard should be pasted in KWrite. STEPS TO REPRODUCE with LibreOffice Writer 1. Ensure the secondary clipboard contains some text 2. Open KWrite and LibreOffice Writer side by side 3. From KWrite directly click on LibreOffice Writer and drag cursor to select text 4. Paste primary clipboard to KWrite 5. Repeat 3. and 4. OBSERVED RESULT Text will be text selected within LibreOffice Writer, but secondary clipboard will be pasted in KWrite. EXPECTED RESULT Text will be text selected within LibreOffice Writer, but primary clipboard should be pasted in KWrite. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.15.4-arch2-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION I'm not sure if 6.4.0 is the first version this occurs, maybe even earlier.
ADDENDUM: I forgot to mention that everything works fine with Firefox.
UPDATE: Moved this bug here since it can only be reproduced while clipboard widget is enabled. 1) When disabling the widget from systray, selecting 'disabled' and pressing *OK* instead Apply causes plasmashell to crash. Same as enabling it, but also causes to append empty line in clipboard history. (Maybe even after system restart) 2) It seems the KWin Debug Console alters the paste output (sometimes when launched several times), while text is pasted mostly with LO Writer. Usually, it shows (and is pasted) only the first character.
(In reply to witchhunter from comment #2) > UPDATE: Moved this bug here since it can only be reproduced while clipboard > widget is enabled. > > 1) When disabling the widget from systray, selecting 'disabled' and pressing > *OK* instead Apply causes plasmashell to crash. Same as enabling it, but > also causes to append empty line in clipboard history. (Maybe even after > system restart) > > 2) It seems the KWin Debug Console alters the paste output (sometimes when > launched several times), while text is pasted mostly with LO Writer. > Usually, it shows (and is pasted) only the first character. this could be the right path, i have similar problems until i clean the clipboard history from that widget
(In reply to andrew from comment #3) > this could be the right path, i have similar problems until i clean the > clipboard history from that widget Not really a workaround, since the moment clipboard is not empty the problems reappear. And even when clipboard is empty, what is stated in UPDATE comment still stands.
Created attachment 185045 [details] Video of the bug I think I have a reliable way to reproduce this. It is quite finicky, I spend and hour trying to make it precise. I took a video of it that is attached. STEPS TO REPRODUCE with LibreOffice Writer 1. Open Kate and LibreOffice Writer side by side 2. Write "First [ENTER] Second [Enter] blah" into Writer and ensure the secondary clipboard contains some text ("Blah") by selecting it and pressing CTRL+C - focus stays in Writer 3. In LibreOffice Writer and DRAG (!) cursor to select text ("FIRST"): DO NOT make any unnecessary clicks, DO not double click to select, DO NOT use keyboard arrow and CTRL to select, it only works with selection by mouse dragging 4. Paste primary clipboard to Kate with middle click or CTRL+SHIFT+INS ("Blah" is pasted) 5. From Kate go back to LibreOffice Writer (without clicking it first) and drag cursor to select some other text text ("SECOND") 6. Paste primary clipboard to Kate with CTRL+SHIFT+INS "SECOND" is pasted) 7. Go back to 3. and you can repeat as long as you want (just make sure you do not click on Writer and possibly Kate before selecting) Can anybody please confirm? It seems almost like some kind of race condition (I think I once reproduced it when two Kate windows were side by side, but there it was extremely tricky to trigger and maybe I was just hallucinating after all the clicking). It depends on two things A) how do I select (double click or drag?) B) windows must not be clicked unnecessarily. I have "Focus Follows Mouse" set, but with "Click to Focus" it seems to also accur.
One last thing: I do not have set Klipper to keep PRIMARY selection history (because of this bug: https://bugs.kde.org/show_bug.cgi?id=498894 ). I can confirm this does not happen when I disable Klipper.
Cannot reproduce in 6.5. Maybe it's already fixed?
(In reply to Fushan Wen from comment #7) > Cannot reproduce in 6.5. Maybe it's already fixed? Still reproducible in Neon Unstable. Tried it with different mouses. The only thing different is that LibreOffice Writer in Neon is XWayland app, so the bug will not occur. But for Meld and Cherrytree is still valid.
I just built Plasma master and there, I cannot reproduce it because Libreoffice will not take into clipboard anything just by selection without pressing CTRL+C. I cannot recreate with Meld.
I have the same issue. Yet I have no idea if this is caused by non-Qt / Qt apps. I only noticed that some applications (eg. LibreOffice) cause a problem. Maybe a related bug from the LibreOffice bugtracker: https://bugs.documentfoundation.org/show_bug.cgi?id=165164
(In reply to BOF from comment #10) > I have the same issue. Yet I have no idea if this is caused by non-Qt / Qt > apps. I only noticed that some applications (eg. LibreOffice) cause a > problem. > > Maybe a related bug from the LibreOffice bugtracker: > https://bugs.documentfoundation.org/show_bug.cgi?id=165164 Also see the video that is attached to the bug report for LibreOffice: https://bugs.documentfoundation.org/attachment.cgi?id=199109
Setting the bug to CONFIRMED as I seem to have the same issue
(In reply to BOF from comment #10) > I have the same issue. Yet I have no idea if this is caused by non-Qt / Qt > apps. I only noticed that some applications (eg. LibreOffice) cause a > problem. > > Maybe a related bug from the LibreOffice bugtracker: > https://bugs.documentfoundation.org/show_bug.cgi?id=165164 While your observation is probably relevant, this bug report is not about secondary clipboard(Ctrl+C), but primary(middle mouse click), so more likely resembles before-mentioned bug 502564. Though I cannot reproduce it with Version: 25.8.2.2 (X86_64) / LibreOffice Community; UI render: default; VCL: kf6 (cairo+wayland) Since this seems to bring some CONFUSION, I tested it with default settings on EndeavourOS bare metal KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Kernel Version: 6.17.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Graphics Processor 1: Mesa Intel® Iris® Xe Graphics Graphics Processor 2: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2 and, KDENeon Unstable VM (with shared memory/clipboard disabled) Weird that others couldn't fully reproduce it, so perhaps video attachment would help. Notice the red title-bar which represents the active window.
Created attachment 185872 [details] text_on_some_windows_cannot_be_selected
Operating System: EndeavourOS KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.20.0 Qt Version: 6.10.1 Kernel Version: 6.12.61-1-lts (64-bit) Graphics Platform: Wayland I too have the problem, and it does a few things way out of whack in LibreOffice Writer. So in addition to the above: It messes up Writer within itself: Once it flips out, copy something in the document, highlight some text somewhere in the document, an paste to replace the latter with the former: it may reformat the text to: different font... In my case because I pasted a larger block of text from the web, and then reformatted it in Writer, stripped out some fluff, added and reworded, and then after all that on paste, it pastes in the first letter only of the copied text, but with a bullet or numbered list, it has the number or bullet, the indentation and the first letter: IT's FREAKING ME OUT MAN! Have the clipboard manager disabled now, but I'm working between multiple documents and apps doing different things, where the dual clipboard, and history come in real handy, but it's messing with my work flow. I hope someone finds the problem soon, but will be patient. I am not going to go back to X11, as was suggested elsewhere, with so much working great in KDE/Wayland; It's the GTK apps giving me most of my problems, and persisting for a very long time.
It would be useful to know whether this problem continues to happen in the upcoming KDE Frameworks 6.22 release next month. A major Wayland clipboard fix landed there.
I already could not reproduce on October 16 (previously I could reproduce).
(In reply to tomashnyk from comment #17) > I already could not reproduce on October 16 (previously I could reproduce). Well, I looked at your video, and you are copying from Writer into a Kate, and it looks like in that case it's in copying where writer isn't copying anything, but rather falling back to a previously copied word "Bla". It's even stranger copying text from a non GTK app under Wayland into writer (AFAIK X11 doesn't have the problem): So try it the other way around and copy from Kate and paste it into writer; In reality you only need to grab some text from a non GTK app, paste it into writer, which will work if you just opened a document in Writer. After that is when the problems start happening: Edit the text, format it in a few ways, differing text sizes, using a bulleted or numbered list... especially add new text (by typing) just copy and paste to move text snippets around in writer itself and you will get errors, including it falling back to the formatting when you first pasted the text from the non GTK app into the writer document. If you cannot reproduce it, maybe as I just did in trying to explore more it all worked right, and then I remembered I had the clipboard manager disabled as a work around! If you did so too, enable it first, and see if the problem persists.
(In reply to witchhunter from comment #13) > While your observation is probably relevant, this bug report is not about > secondary clipboard(Ctrl+C), but primary(middle mouse click), so more likely > resembles before-mentioned bug 502564. Though I cannot reproduce it with > Version: 25.8.2.2 (X86_64) / LibreOffice Community; UI render: default; VCL: > kf6 (cairo+wayland) > I never could get used to the middle mouse click for being so used to right click > paste, so they must both be primary and on that note: Using [Ctrl] + [c] and [Ctrl] + [v] doesn't seam to work at all in writer.
(In reply to Bob English from comment #18) > (In reply to tomashnyk from comment #17) > > I already could not reproduce on October 16 (previously I could reproduce). > > Well, I looked at your video, and you are copying from Writer into a Kate, > and it looks like in that case it's in copying where writer isn't copying > anything, but rather falling back to a previously copied word "Bla". Yeah, that seems to me to be the original description of the problem (under "STEPS TO REPRODUCE with LibreOffice Writer"). Anyway, somebody needs to try with Kde Frameworks 6.22, as Nate asked. Preferably somebody who can still reproduce it on their system now :-).
(In reply to tomashnyk from comment #20) > (In reply to Bob English from comment #18) > > (In reply to tomashnyk from comment #17) > > > I already could not reproduce on October 16 (previously I could reproduce). > > > > Well, I looked at your video, and you are copying from Writer into a Kate, > > and it looks like in that case it's in copying where writer isn't copying > > anything, but rather falling back to a previously copied word "Bla". > > Yeah, that seems to me to be the original description of the problem (under > "STEPS TO REPRODUCE with LibreOffice Writer"). Anyway, somebody needs to try > with Kde Frameworks 6.22, as Nate asked. Preferably somebody who can still > reproduce it on their system now :-). I just found "This week in Plasma" on KDE Blogs and subscribed: I frequently look for stuff I expect to find there, but in the ~15 years I've been using Plasma didn't come across it, or if I did, I didn't scroll far enough down to find the subscribe link: So many KDE sites. It's always good to know what your DE and important software's devs are working on, and what to look forward to. The system tray and some of the stuff in it have needed work for a long time, but with such a huge amount of stuff KDE makes they still keep improving it at a fast pace compared to other DE's and projects: I love it, and snafus like this are nowhere near a reason to switch DE's, only to have far fewer features, less control! Been there done it, and now that Cosmic is all the rage, it still doesn't impress me in comparison. Distro and DE hopping is way over rated! :>)
Created attachment 187857 [details] Libreoffice_first_selection | Meld_first_selection | second_selection Side by side clipboard content on first selection LO and Meld, and on second selection
(In reply to Nate Graham from comment #16) > It would be useful to know whether this problem continues to happen in the > upcoming KDE Frameworks 6.22 release next month. A major Wayland clipboard > fix landed there. -Tested now on bare metal, new install- Operating System: KDE neon Unstable Edition KDE Plasma Version: 6.5.80 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.14.0-37-generic (64-bit) Graphics Platform: Wayland - The problem persists with Meld, Cherrytree and LibreOffice "UI render: default; VCL: kf6 (cairo+wayland)" - but not "VLC:gtk3",which is not affected - Since this is on bare metal new install, it is weird others cannot reproduce. - The bug can be simplified. In light of other posts it can be narrow down to the same window: select -> paste_primary -> select -> paste_primary and the secondary is pasted. If before second paste user clicks with mouse on some text field in window, the bug will not occur. - The weird thing could be noticed with Meld. Since it has two panes, for left and right file, the bug can be reproduced while working on the same pane. But if the user select-paste text on one, than the other pane, bug will not occur.
Decided not to comment. So where is the "Cancel" button? This sight has a few odd changes, and not for the better.
(In reply to witchhunter from comment #23) > (In reply to Nate Graham from comment #16) > - The bug can be simplified. In light of other posts it can be narrow down > to the same window: > select -> paste_primary -> select -> paste_primary and the secondary is > pasted. Confirming that this way, the bug can be reproduced. It is also Wayland specific. I forgot that I have export GDK_BACKEND=x11 in my .profile to force GTK apps to xwayland making sure they work with Locally integrated menus/global menus. Running Meld with GDK_BACKEND=wayland immediately yielded the bug. Kinfo now gives this: Operating System: Fedora Linux 43 KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.10.1 Kernel Version: 6.17.12-300.fc43.x86_64 (64-bit) Graphics Platform: Wayland
The situation just got worsened on EndeavourOS. Now the primary clipboard stopped working in Meld and Cherrytree altogether. Operating System: EndeavourOS KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.24.0 Qt Version: 6.11.0 Kernel Version: 6.19.11-arch1-1 (64-bit) Graphics Platform: Wayland
(In reply to witchhunter from comment #26) > The situation just got worsened on EndeavourOS. Now the primary clipboard > stopped working in Meld and Cherrytree altogether. > I'm on Endeavour too, fully up to date, and still have the problem, but it isn't worse. I don't use either Meld or Cherrytree, and I'd have to assume those are just effected apps where it doesn't work at all, I have at least one that showed the same behavior: in both cases when overwriting, the highlighted text just flashes as if it pasted something but it made no change? If so it's not new, and very most likely related. Turning off (Disabling) the clipboard app in the system trey fixes it, but of course at a loss of having the clipboard history, so I have it on for some things, and off for other, and of course it's no fun, but works for now.
(In reply to witchhunter from comment #26) > The situation just got worsened on EndeavourOS. Now the primary clipboard > stopped working in Meld and Cherrytree altogether. This is likely caused by GNOME disabling the feature by default, and would be unrelated to the issue here. To rule that out, test with non-GTK apps like Element or Discord.
(In reply to Nate Graham from comment #28) > This is likely caused by GNOME disabling the feature by default, and would > be unrelated to the issue here. To rule that out, test with non-GTK apps > like Element or Discord. *Disregard comment 26.* You're right, I was looking for some envars and it totally slipped my mind I could run gsettnigs on Plasma, sry. The bug is not reproducible with Element, but couldn't try Discord since I don't have an account. As for LO, the bugs seems to be entitled to VLF qt6/kf5. Perhaps best illustrated with this nasty occurrence https://bugs.documentfoundation.org/show_bug.cgi?id=171957 reproduced today on Fedora Gnome, LOv26.2.4.2. Since there is no issue with gtk3 version, I'll try it for now and hopefully not have the same breakage as described in comment 10 :)
Putting SyncClipboards=false NoEmptyClipboard=true into ~.config/klipperrc and restartning plasma (with plasmashell --replace) solves the issue for me, could anybody confirm? I suspect the root cause of this is the same for https://bugs.kde.org/show_bug.cgi?id=509975 I got an even easier way to trigger this, for any GTK3 or GTK4 application (I tried Meld and gnome-text-editor and Subtitleeditor) is to just select two characters, paste and select another two characters and paste. I think the issue is because GTK applications send a new clipboard select event every time the cursor moves when selecting (actually more than one per character) and also send empty clipboard when nothing gets selected (like when you just click on text edit area to move cursor - that clears the primary clipboard). This clearing touches codepaths in clipper that should not fire when the empty is from primary selection - in trying to prevent empty clipboard, it uses the last clipboard entry, which is where this bug comes from.
(In reply to tomashnyk from comment #30) > Putting > > SyncClipboards=false > NoEmptyClipboard=true > > into ~.config/klipperrc and restartning plasma (with plasmashell --replace) > solves the issue for me, could anybody confirm? I suspect the root cause of > this is the same for https://bugs.kde.org/show_bug.cgi?id=509975 > Bug still reproducible.
*** Bug 420758 has been marked as a duplicate of this bug. ***
@witchhunter Actually, I put the wrong config, putting NoEmptyClipboard=false and restarting clipper (sadly it needs a logout until https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6983 is merged) should fix the bug (but when an app that originated a clipboard closes, you will lose clipboard content). I think this is due to https://gitlab.gnome.org/GNOME/gtk/-/work_items/317 - it will be almost twenty years and GTK insist on this, very sad. MR forthcoming, anyway.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9828
The fix is actually entirely on kwin side, but I am not sure this should be reassigned to it.
(In reply to tomashnyk from comment #33) > NoEmptyClipboard=false and restarting ... That's fantastic. Can confirm it works, selection and primary clipboard. > but when an app that originated a clipboard closes, you will lose clipboard content Actually clipboard is not entirely lost, just ability to paste it. It is in klipper and can be reactivated simply by clicking last entry. This has significantly lower impact anyway. TYVM
Git commit d9de57d2bda68e6964a904ca7454946515de5435 by Vlad Zahorodnii, on behalf of Tomáš Hnyk. Committed on 09/09/2026 at 13:44. Pushed by vladz into branch 'master'. wayland: Only allow replacing a destroyed primary or clipboard selection GTK applications drop the selection when the user clicks away: https://gitlab.gnome.org/GNOME/gtk/-/work_items/317 x-kde-onlyReplaceEmpty is meant to be used by klipper only when an application closes, as that allows klipper to preserve clipboard/selection content. So use the replacement only when the connection to the application closes. This has to be done on kwin side, as kwin knows this and klipper does not. Note that this works only for Wayland. On Xwayland, the client this commit looks up is always null, so gating does not work and klipper (or any other user of x-kde-onlyReplaceEmpty) is left with the previous check, which allows it to only replace clipboard or selection buffers that nobody owns. M +9 -10 src/wayland/seat.cpp M +2 -0 src/wayland/seat_p.h https://invent.kde.org/plasma/kwin/-/commit/d9de57d2bda68e6964a904ca7454946515de5435
*** Bug 525896 has been marked as a duplicate of this bug. ***