Bug 228776

Summary: Copy and Paste occasionally does not work despite text is present in clipboard
Product: [Unmaintained] klipper Reporter: Jan Uhlir <espinosa_cz>
Component: generalAssignee: Esben Mose Hansen <kde>
Status: RESOLVED WORKSFORME    
Severity: normal CC: adaptee, adriano.lols, de.techno, dimsuz, espinosa_cz, mathias, muzenbaher, nikisch, rossi.f
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Mandriva RPMs   
OS: Unspecified   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Jan Uhlir 2010-02-27 17:06:20 UTC 
Version:            (using KDE 4.3.5)
Installed from:    Mandriva RPMs

Copy and Paste does not work even in the text is present in clipboard, you can see it Klipper, and it is on the top of the history list, as expected. Nothing suspicious here. But “Paste” pastes nothing. 

If you open it in Klipper and explicitly click on the item, Paste starts to work. It seems to be that the clipboard item is just not “active”. This however is not indicated in Klipper. It is on the top.

It is difficult to reproduce. It is always happening when you are “not looking” and “not prepared”. It happens quite scarce. Lets say once an hour on average. I was never able to detected what exact consequences can trigger this. Whenever I have some theory how to reproduce it for sure, next try will prove I am wrong. 

This is happening for many years, even from KDE 3 times, as far as I can remember. It is still present in KDE 4.3.5.

How to reproduce:
Let's say I wan to copy full path, URL of a particular file, to OOo or Kate. 
1. Start fresh KDE session. Select file in Dolphin, locate the file, do Copy (Ctrl+C)
2. In OpenOffice.org do Paste or Paste Special. Or Kate or KWrite and do paste.
3. Nothing happens.
4. However – open Klipper, the file URL is on the top, click on it. Now the paste works.

However if I repeat the steps just after it, it works. As I said it is tricky to reproduce.

My clipper config:
Clipboard Actions – disabled.
Prevent empty clipboard – ON (don't know what is good for, was a default setting)
Separate clipboard and selection (don't know what is good for, was a default setting)

It never happens, as far as I remember, when using C&P in the same applications. It appears only when coping form one application to another.
Comment 1 Jan Uhlir 2010-02-27 17:13:09 UTC 
This may be related to bugs #228737 and #225681:

https://bugs.kde.org/show_bug.cgi?id=228737 - Klipper often does not activate last copied/cut entry, and I have to switch between entries to select the last one.

https://bugs.kde.org/show_bug.cgi?id=225681 - Klipper ignores copying, have to copy twice
Comment 2 Esben Mose Hansen 2010-03-01 11:22:56 UTC 
I cannot reproduce this :( A few questions: Do you close Dolphin before copying? By fresh session, do you "start new session" and the test right away?
Comment 3 Mathias 2010-03-01 14:31:54 UTC 
I can definitely confirm this bug. But it strikes me only since KDE 4 (until now, 4.3.5) - version 3 had no such issue for me. I had this on different machines and different distros (Kubuntu and Gentoo).

Here, I mostly run into this when I want to copy&paste text between different OpenOffice-Windows, but I also had this with other applications. It's always the same scenario as described above: Copy text via Ctl-C or via mouse-marking it, try to paste it in the same document or in another window - nothing pasted. Klick on Klipper, klick on the top entry in the list, which is the desired text, go back to the working window, try to paste again, success.

I consider this quite a nasty thing that really should be dealt with, but did not find anything that definitely would trigger this.
Comment 4 Esben Mose Hansen 2010-03-01 15:32:30 UTC 
@Mathias: That is probably another bug; there was a race between the new Qt4 XFixes-enabled clipboard and the good old klipper xfixes code. In 4.4, the klipper xfixes code is disabled, so this should no longer occur. It has, unfortunately, exposed a possible bug in the QT4 clipboard code concerning application that terminates while holding the clipboard.
Comment 5 Mathias 2010-03-01 17:20:15 UTC 
Hm, seems that you are right since the problem I described had nothing to do with copied FILES but only text and closed applications also were not involved. Just in case it makes sense to add: when pasting failes, the checkbox before entry no. 1 in the klipper list is unchecked. Only after manually check it, pasting works. 
But well, if it's solved in 4.4 then I have to be patient and wait for 4.4 - let's hope.
Comment 6 Jan Uhlir 2010-03-02 22:49:44 UTC 
Yesterday, I caught it when copying text from Firefox to OOo. It pasted previous (old) value in clipboard (I do use C&P a lot). Interestingly, when it opened Klipper the new value was there, at the top of history, so everything looked OK. It just looked as if the new value is not "active". When I clicked on it it worked.

I was to able to reproduce again. So unfortunately I don't know what would happen if I did not click 

I have to confirm Mathias discovery that failed C&P is easily fixed by "reiterating". If paste fails (paste nothing or rarely the old value) simply go back to original, usually still opened application, the text is usually still selected, hit Ctrl+C again and return to target application and do paste again. The bug never repeat itself again on the same spot. 

Possible clipboard conflict with another clipboard (does X server has its own?)

Is it possible that I hit mouse middle button by mistake in the middle of C&P operation thus deactivating the just selected content? (I never use middle mouse button for C&P purposes)

I will keep an eye on the circumstances and update this bug report if I find something worthy.
Comment 7 Adriano Moura 2010-04-15 01:35:58 UTC 
Seems to be a regression in KDE 4.4.2

4.4.0 and 4.4.1 had this nailed down. But after the newer update, Once I close any applications which has any entry on the clipboard, they stop working. Klipper still lists everything right, but you have to reselect one of then to get your clipboard back.

I hope this can be fixed for the next point release. It's REALLY annoying.
Comment 8 Anton 2010-05-09 22:25:12 UTC 
(In reply to comment #7)
> Seems to be a regression in KDE 4.4.2

The same problem.

Arch Linux
KDE 4.4.3
Qt 4.6.2
Comment 9 Deem 2010-05-09 23:19:37 UTC 
have this bag on any distributives with KDE4 (and 4.4.3 to) i636 and x86_64

keyboard layout en+ru
using xneur (demon without gui)
Comment 10 Salvatore 2010-05-24 00:12:53 UTC 
*** This bug has been confirmed by popular vote. ***
Comment 11 dE 2010-07-04 06:09:18 UTC 
I confirm this very annoying yet 'one of the' kde bugs.
Comment 12 dE 2010-07-04 06:10:14 UTC 
On Gentoo i.e.
Comment 13 dE 2010-07-04 09:31:30 UTC 
My problem got solved after configuring clipper in a better way...

Retracting votes...
Comment 14 Mathias 2010-09-08 22:25:41 UTC 
I'm on KDE 4.4.5 now, haven't encountered the problem for a while. Probably solved in this version?
Comment 15 Jekyll Wu 2011-12-23 04:13:13 UTC 
I failed to reproduce the reported problem using 4.7.x. Feel free to reopen or leave comment if it still happens in recent versions.