Bug 506325

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