http://bugzilla.novell.com/show_bug.cgi?id=572638 http://bugzilla.novell.com/show_bug.cgi?id=572638#c0 Summary: klipper sometimes looses primary or clipboard selection content Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: Other OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace AssignedTo: kde-maintainers@suse.de ReportedBy: guido+opensuse.org@berhoerster.name QAContact: qa@suse.de Found By: --- Blocker: --- 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 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.