Bugzilla – Bug 572638
klipper sometimes looses primary or clipboard selection content
Last modified: 2010-02-12 15:51:44 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091201 SUSE/3.5.6-1.1.1 Firefox/3.5.6 This is a summary of upstream bug https://bugs.kde.org/show_bug.cgi?id=166606 The code in klipper which either polls for changes or uses XFixes selection events in order to detect an application assuming selection ownership does not work reliably with newer Qt versions, sometimes wrongly treating the selection as empty. Furthermore, if polling the owning application about the selection formats takes too long the selection will be treated as empty, too. In effect this means that klipper wrongly replaces new content in either the primary or clipboard selection with the previous content. When the application originally owning the selection, that is the one copied or cut from, is closed the data will be lost. Even worse, when pasting one might unexpectedly receive the the previous content of the clipboard selection which can have unexpected side effects, e.g. when pasting into an xterm. This bug has been fixed in KDE SVN by retiring XFixes support in klipper and relying on the XFixes support on QClipboard and by querying the selection-owning application for the selection format again if the selection appears empty in order to work around the timeout issue. The relevant commits are 1055587, 1059041, and 1072867. Reproducible: Always
*** Bug 552200 has been marked as a duplicate of this bug. ***
Great news, Guido, thanks! Do we have a build service project, where the fixes should appear soon? I'd like to test it.
All three fixes are in 4.4RC2, so you could try KDE:KDE4:Factory:Desktop. I tried to apply the patches to kdebase4-workspace from 11.2 but some internal data structure of the clipboard/primary selection history has changed in history.cpp and since I'm not proficient with Qt I'd rather leave the backporting to someone else. It should be easy though, it's a small changeset.
This seems to be working now in rc2 (thank goodness!). Can we close the bug? Cheers Steve
(In reply to comment #4) > This seems to be working now in rc2 (thank goodness!). Can we close the bug? No, this has been fixed for quite a while in KDE trunk and I intentionally filed this bug against 11.2 in order to request a backport of the relevant commits I listed above.
I have submitted r1055587 to STABLE. The other two commits don't apply cleanly and it appears they are not relevant for the 4.3 branch. Please test.
Seems to work fine.