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.