Bug 144949

Summary: using shift+delete as 'cut' in applications can occasionally make klipper drop the content
Product: [Applications] klipper Reporter: Sune Vuorela <debian>
Component: generalAssignee: Esben Mose Hansen <kde>
Status: RESOLVED FIXED    
Severity: normal CC: adaptee, dimsuz
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:

Description Sune Vuorela 2007-05-02 12:37:57 UTC
Version:            (using KDE KDE 3.5.6)
Installed from:    Debian testing/unstable Packages

Hi!

UNder some specific circumstances, it seems like klipper drop data.

Steps:
1) Have 'syncronize content of clipboard and selection' set in the klipper configuration
2) open some program. I have used kate.
Enter some lines. For easy recognizing, I use
aaaa
bbbb
cccc

3) with the mouse, select a line, aaaa and paste it into the bottom of the document. It should now say
aaaa
bbbb
cccc
aaaa

4) With the keyboard (arrowkeys + shift) to select a line, bbbb, and press shift+delete for cut.

5) Go to the end of the document and paste with crtl-v or with shift+insert
The document now says
aaaa
cccc
aaaa
aaaa

The 'bbbb' line seems to be lost - and aaaa which was supposed to be the previous content is pasted instead.

I can reproduce this in at least kate, kwrite and in kmails text editor.

If crtl-x is used to cut instead, there is no problems.

This is originally reported in debian as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421504

/Sune
Comment 1 Dmitry Suzdalev 2008-11-26 08:06:11 UTC
Confirmed for klipper in 4.2 trunk
Comment 2 Esben Mose Hansen 2009-10-16 22:20:20 UTC
This seems to work now. Sune, could you affirm?