Bug 144949 - using shift+delete as 'cut' in applications can occasionally make klipper drop the content
Summary: using shift+delete as 'cut' in applications can occasionally make klipper dro...
Status: RESOLVED FIXED
Alias: None
Product: klipper
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Esben Mose Hansen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-02 12:37 UTC by Sune Vuorela
Modified: 2011-11-06 20:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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?