Bug 572638

Summary:	klipper sometimes looses primary or clipboard selection content
Product:	[openSUSE] openSUSE 11.2	Reporter:	Forgotten User cAXlJ_FoSf <forgotten_cAXlJ_FoSf>
Component:	KDE4 Workspace	Assignee:	E-mail List <kde-maintainers>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P1 - Urgent	CC:	forgotten_kHYb7eJGnH
Version:	Final
Target Milestone:	---
Hardware:	Other
OS:	openSUSE 11.2
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Forgotten User cAXlJ_FoSf 2010-01-21 11:52:47 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

Comment 1 Forgotten User cAXlJ_FoSf 2010-01-21 11:59:09 UTC

*** Bug 552200 has been marked as a duplicate of this bug. ***

Comment 2 Juergen Weigert 2010-01-21 19:04:33 UTC

Great news, Guido, thanks!

Do we have a build service project, where the fixes should appear soon?
I'd like to test it.

Comment 3 Forgotten User cAXlJ_FoSf 2010-01-21 20:01:04 UTC

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.

Comment 4 Forgotten User kHYb7eJGnH 2010-01-25 06:18:03 UTC

This seems to be working now in rc2 (thank goodness!). Can we close the bug?

Cheers
Steve

Comment 5 Forgotten User cAXlJ_FoSf 2010-01-25 10:41:42 UTC

(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.

Comment 6 Lubos Lunak 2010-02-01 16:53:51 UTC

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.

Comment 7 Lubos Lunak 2010-02-12 15:51:44 UTC

Seems to work fine.