Sometimes you copy a piece of text, and you try to paste it, but the system pastes an old Klipper entry. So you try to select the proper entry in Klipper but it does not activate it and keeps memorized an old entry. To exit from this deadlock you must copy another piece of text Reproducible: Couldn't Reproduce
How to reproduce: Open a editor (e.g. kate) and write in the first line "test1" and in the second line "test2". Now select the word test1 and copy it to the clipboard with ctrl-c. Now you can paste it with ctrl-v. Now select the word test2 with your mouse. Now you can paste the word test2 with the middle mouse button. The word test1 is still pasted with ctrl-v. If you try to select the top item in klipper (the word test2) the word test1 is still pasted by ctrl-v. It is necessary to select another entry in Klipper before you can select the entry test2 and paste it with ctrl-v.
Another variation of this bug is as follows: 1) Copy URL or text in an application (e.g. Firefox) 2) Close application 3) Try to paste. Nothing get pasted. In KDE4 the copied item "loses focus" when closing the app, and you have to select it again from Klipper (dunno if a bug or intended feature) 4) The item (URL or text) is the first item in the menu. Click on it 5) The item isn't actually selected. Select another item (e.g. the one below it), then select the intended item for it to be selected and pasted
Same here I copy text, and it makes it into Klipper, but I try and paste, and nothing will paste. I select the item from Klipper's history but there is still no checkbox next to it. I have to select something else in the history list (which will show a checkbox) *then* can select what I just copied and paste it. Just double checked, and it's definitely reproducible. Could it be conflicting with the "built-in" klipper that cannot be turned off (though you can disable the icon)?
@EMR_Kde: you just copied the same comment into three bug reports. That's not helpful, rather the opposite.
(In reply to Martin Gräßlin from comment #4) > @EMR_Kde: you just copied the same comment into three bug reports. That's > not helpful, rather the opposite. Sorry about that, each time I kept digging through the reports they came closer and closer to what I was experiencing. Won't happen again! :)
As per an IRC discussion, the reporter is actually using the plasmoid, not the Klipper application.
Today I am experiencing a variation of the problem: I copy a text or something else, then I try to paste it but it does not actually paste anything. I repeat the action and this time it works
The bug evolution is: you copy a piece of text, you try to paste it and you got nothing pasted. You go in klipper plasmoid, and you see at the top of the stack an empty entry. You delete it and you try again
I have tried both, and noticed the same behavior. Could it be related my my mouse settings? I have focus-follows-mouse, but it doesn't raise the window. So for example, I have two windows open, one in the background, and one in the foreground. I copy data from the foreground window, then hover the background window, which gets focus, and paste. Most times it works, sometimes it doesn't. In any case, if I go to the klipper app, and I select the item I just copied, it /should/ have a checkbox, and just doesn't, unless I select something else in the list and select back the primary item. I mention the focus-follows-mouse, because I have a similar issue when copy-pasting from screen shots (selecting "PrtScrn" button to bring up Spectacle). It seems like the image ends up blank, sometimes... again randomly. I take it the popup menu, or app itself may be interfered with by the window focus policy. Don't know, just throwing it out there. I have attached my policy to this bug report.
Created attachment 102178 [details] screenshot of focus-follows-mouse policy Window focus policy on KDE kinit-5.21.0-15.1.x86_64 spectacle-15.12.3-11.4.x86_64 plasma5-pa-5.5.5-9.1.x86_64 plasma5-addons-kimpanel-5.5.5-9.1.x86_64 plasma5-desktop-5.5.5-20.1.x86_64 plasma5-pk-updates-lang-0.2-5.1.noarch plasma5-desktop-branding-openSUSE-13.3-35.1.x86_64 plasma5-workspace-lang-5.5.5.2-12.1.noarch plasma5-workspace-branding-openSUSE-13.3-35.1.x86_64 plasma5-addons-lang-5.5.5-9.1.noarch plasma5-workspace-libs-5.5.5.2-12.1.x86_64 plasma5-workspace-5.5.5.2-12.1.x86_64 plasma5-pa-lang-5.5.5-9.1.noarch plasma5-workspace-devel-5.5.5.2-12.1.x86_64 plasma5-desktop-lang-5.5.5-20.1.noarch plasma5-session-5.5.5-9.1.noarch plasma5-pk-updates-0.2-5.1.x86_64 plasma5-addons-5.5.5-9.1.x86_64
Git commit 37014e643cec4ee9aed54421f66c675e1bc91b70 by Luboš Luňák. Committed on 17/04/2017 at 11:13. Pushed by lunakl into branch 'master'. selecting the topmost klipper item should always set it as clipboard contents Without this, that wasn't always the case if the top item was only the mouse selection. This was presumably broken by 2e47d84772. Also explicitly check the popup item, since it's now owned by Klipper. Related: bug 251222 M +11 -0 klipper/history.cpp M +1 -0 klipper/history.h M +1 -0 klipper/klipper.cpp M +7 -0 klipper/klipperpopup.cpp M +1 -0 klipper/klipperpopup.h https://commits.kde.org/plasma-workspace/37014e643cec4ee9aed54421f66c675e1bc91b70
To explain the actual bug you're doing the workaround for: Qt XCB had a bug in it that meant it wouldn't signify clipboard changes. This is fixed: http://code.qt.io/cgit/qt/qtbase.git/commit/?id=291eba6f8099a0fec8fbd9cf8a1fb67e5c9f4f8d This is fixed in Qt 5.8.0 not 5.7.x This is what caused klipper to not re-populate the blank clipboard and take ownership of the selection. This is what gets it in the state where the topmost item is not in sync with the clipboard.
Git commit f78b0869f01d255d0e17a0a246e5a9456f2bba4e by Luboš Luňák. Committed on 26/04/2017 at 09:06. Pushed by lunakl into branch 'Plasma/5.8'. selecting the topmost klipper item should always set it as clipboard contents Without this, that wasn't always the case if the top item was only the mouse selection. This was presumably broken by 2e47d84772. Also explicitly check the popup item, since it's now owned by Klipper. Related: bug 251222 M +11 -0 klipper/history.cpp M +1 -0 klipper/history.h M +1 -0 klipper/klipper.cpp M +7 -0 klipper/klipperpopup.cpp M +1 -0 klipper/klipperpopup.h https://commits.kde.org/plasma-workspace/f78b0869f01d255d0e17a0a246e5a9456f2bba4e
Git commit 921f89cb62e2fa118ba16ea87bcec0ba41751a82 by Luboš Luňák. Committed on 26/04/2017 at 09:07. Pushed by lunakl into branch 'Plasma/5.9'. selecting the topmost klipper item should always set it as clipboard contents Without this, that wasn't always the case if the top item was only the mouse selection. This was presumably broken by 2e47d84772. Also explicitly check the popup item, since it's now owned by Klipper. Related: bug 251222 M +11 -0 klipper/history.cpp M +1 -0 klipper/history.h M +1 -0 klipper/klipper.cpp M +7 -0 klipper/klipperpopup.cpp M +1 -0 klipper/klipperpopup.h https://commits.kde.org/plasma-workspace/921f89cb62e2fa118ba16ea87bcec0ba41751a82