Open Bug 1122497 Opened 8 years ago Updated 4 months ago

Text selection and cursor movement using arrow keys is counter-intuitive and inconsistent


(Thunderbird :: Message Compose Window, defect)

31 Branch
Windows 7


(Not tracked)



(Reporter: ian.thomson, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Steps to reproduce:

1. Create a new message or reply to an existing message. 
2. Include one or more carriage returns between paragraphs, plus left parentheses and hyphens within the text body. Paste in the following text as a test sample:
"The quick - brown (fox) jumps

over the ( lazy-dog)"
3. Position the cursor at the start of the text. Move it right with Crtl-Right Arrow. Notice that it stops to the left of the first hyphen then to the left of "brown". Continue, noticing that it stops on the left parenthesis then moves directly to "jumps". Reverse direction with Ctrl-Left Arrow. Notice that the cursor now stops on "fox" but not the parenthesis, and on "brown" but not the hyphen. Repeat this test on the second line and see that when moving right, the cursor stops on both the parenthesis and "lazy" but when moving left, only on "lazy", which is also inconsistent but a different behaviour. The cursor behaves correctly on the cursor with no spaces in "lazy-dog". Similar behaviour to the above occurs when selecting text using Shift-Ctrl-Arrow Keys. 
4. Place the cursor to the left of "The". Select the whole line with Shift-End. Press Delete or type a new character. Notice that the line's text disappears and the line below does not move. This is the same behaviour as double clicking the first word with the mouse then hold and drag the cursor to the end of the line. Undo the deletion (Ctrl-Z). Position the cursor again to the left of "The". Press Ctr-Shift then repeatedly Right Arrow until the whole line including "jumps" is selected. Press Delete or type a new character. Notice that the whole line plus any white space up to the first visible character on the next line is also deleted. This is incorrect behaviour, different from mouse usage. 

Actual results:

The above behaviour means that use of arrow keys for cursor editing is slow, needs additional steps to correct for the inconsistencies is counter-intuitive and frequently causes mistakes.

There may be other incorrect behaviour associated with other characters and white space, but these have not yet been found.

Expected results:

Cursor movement and text selection should have similar behaviour using both mouse and keyboard. It should behave the same when moving in both directions and should not be changed by intervening spaces. Selection to the end of the current line should not also select all following white space without further user action such as one additional press of Ctrl-Shift-Right Arrow.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.