Bug 334571

Summary:	Replacing selected text with a space just cancels the selection
Product:	[Applications] kmail2	Reporter:	resplin <richard-oss>
Component:	composer	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kdebugs, montel
Priority:	NOR
Version:	4.13.0
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:	4.13.2
Sentry Crash Report:

Description resplin 2014-05-10 04:54:57 UTC

I upgraded my Fedora 20 install to use tho KDE 4.13.0 packages from the Fedora development repository in order to replace nepomuk with baloo.

I have the habit of typing, deciding that I want to get rid of what I typed, selecting the text including the surrounding spaces, pressing space, and typing my replacement text. Since upgrading KMail, pressing space merely cancels the selection leaving the cursor at the start of what was the selection. Then my typing goes in prior to the text I was trying to replace.

Reproducible: Always

Steps to Reproduce:
1. Compose a new email
2. Select some text
3. Press the space bar
Actual Results:  
The selection is cancelled, and the cursor sits prior to the previously selected region.

Expected Results:  
The selection should be replaced with a space.

This does not happen in any other application. I have tested Firefox, LibreOffice, Konversation, KWrite, Choqok, and Telepathy.

This does not happen with any other character. Pressing "a" will replace the selection with the letter "a".

Environment: Fedora 20 pulling KDE 4.13.0 from apt.kde-redhat.org

Comment 1 resplin 2014-05-10 17:15:30 UTC

Someone on #kde on Freenode replicated the issue with KDE 4.13.0 on OpenSuSE 13.1. For them, the space was being inserted after the selection instead of before.

It appears that the space is inserted on the side of the selection which is the cursor position. Drag right to left, the space is before. Drag left to right, the space is inserted after. Double-click to select, and the space is inserted after.

Regardless, the space should replace the selection, so it is clearly a bug.

Comment 2 Laurent Montel 2014-05-16 09:42:08 UTC

Fixed in 4.13.1

Comment 3 Gunter Ohrner 2014-05-18 07:37:44 UTC

I'm running 4.13.1 on Kubuntu 14.04 (About dialog: KMail Version 4.13.1 unter KDE 4.13.1) and sadly the bug is not fixed.

The behaviour if SPACE is pressed is as expected if the line is quoted (which seems to be what your if statement checks), but it's still wrong if a line is not quoted. In this case, an ENTER or SPACE does not replace the selected text, but simply adds the newline or space character in front of or after the selected text.

Comment 4 Gunter Ohrner 2014-05-18 07:39:29 UTC

Mh, can someone re-open this bug, or should I add a new one for KDE 4.13.1?

Also Bug 334612 looks like a duplicate and also is not fixed in KDE 4.13.1, so maybe it should be tagged / linked accordingly, or also be reopened.

Comment 5 Gunter Ohrner 2014-05-18 08:36:09 UTC

Additional information: If the selection spans multiple lines, some quoted and some not, the behaviour if ENTER or SPACE is pressed does not depend on the selected area but on the row the cursor is positioned in.

If if (parts of) three lines are selected and the cursor is positioned in a quoted line, pressing ENTER or SPACE will replace the selected text by a newline or space character, as expected.

If if (parts of) three lines are selected and the cursor is positioned in a not-quoted line, pressing ENTER or SPACE will simply add a newline or space character in front of or after the selection, contrary to the behaviour of every other GUI text editor I know.

Comment 6 resplin 2014-05-25 07:29:23 UTC

I upgraded Fedora to KDE 4.13.1 from apt.kde-redhat.org/unstable. This bug is still clearly present in KMail.

I would like to change the status to REOPENED, but I don't see how to do that, so I changed it back to UNCONFIRMED.

Comment 7 resplin 2014-07-03 02:46:36 UTC

After using KDE 4.13.1 a while, I figured out that it was fixed in some scenarios, but not others.

After using KDE 4.13.2 for a few minutes, I cannot reproduce this bug.

Resolving as fixed.

Thank you!