859088 - Left/Right Arrow key after selection should move to the beginning/end of selection respectively

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Timwi]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130326150557

Steps to reproduce:

• Select some text in a textbox, e.g. the editing window on Wikipedia.
• Press either the Left Arrow key or the Right Arrow key once.


Actual results:

The selection is removed and the cursor moves one character to the left or right from the position where the selection “ends”, and there is no visual feedback to show whether this is actually the start or the end of the selection (which depends on the direction the selection was created in).


Expected results:

Expected behaviour is for the Left Arrow to move the cursor to the beginning of the selection and the Right Arrow to the end of the selection, and to remove the selection. In particular:

• The expected behaviour is independent of the direction in which the selection was created.
• The cursor should not move beyond the extent of the selection.

This behaviour is exhibited by Google Chrome, Internet Explorer, Qt (and hence, Opera and Skype), Visual Studio (and SQL Management Studio), Metro/WPF, MS Office and Wordpad, Notepad2, Notepad++, Programmer’s Notepad, wxWidgets (e.g. PgAdmin), BeyondCompare’s editor window, POV-ray, ...

The only other code I can find that exhibits Gecko’s behaviour is the outdated Windows API edit control (which includes Notepad). It is outdated because Metro and WPF are obsoleting it.

Comment 1

[Mats Palmgren (inactive)]

Seems reasonable.  It's also what IE10 on Win7 does.  I think it should
be easy to fix since we already have it implemented for other platforms.

If you set the hidden preference layout.selection.caret_style to 2
in about:config, does that give you the expected behavior?

Comment 2

[Timwi]

Yes, it does! It’s really cool that there’s an option for that so I can have my preferred behaviour right now. Thanks!

Since Windows appears to be moving towards behaviour 2, perhaps the behaviour of 0 should simply be changed from “2 for Mac OS, 1 for others” to “2 for Windows and Mac OS, 1 for others”?

Comment 3

[Mats Palmgren (inactive)]

Attachment: fix, for Windows

This should do it.  I expect it will break some tests though:
https://tbpl.mozilla.org/?tree=Try&rev=5814d2130810

Comment 4

[Mats Palmgren (inactive)]

Maybe we should change this behavior on Linux as well?
I tested some native applications in Kubuntu (KDE) and they have the "2" behavior
(unlike Nightly).  Can someone check native applications on Fedora/GNOME please?

Comment 5

[(no longer active)]

Comment on attachment 734728 [details] [diff] [review]
fix, for Windows

Sure.  But please also adjust the comments in all.js.

Comment 6

[Karl Tomlinson (:karlt)]

The behaviour in the GTK file open dialog is that expected in comment 0, so behaving the same for non-native input makes sense.

Comment 7

[Mats Palmgren (inactive)]

One test failed:
toolkit/content/tests/chrome/test_bug451540.xul | Input: highlight correctly remained on text deletion at start 

It appears the editor/ changes are not needed at all for changing the selection
behavior (makes sense in retrospect).  The editor code is only using the caret_style
pref to guide the behavior for "word delete", see bug 350564.
For example, if you have "aaa bbb ccc" and select "bbb" and then do CTRL+BACKSPACE
then the Windows behavior is to first collapse the selection (at start of "bbb")
and then delete the word from there, deleting "aaa ".
I've confirmed that this is what IE10 in Win7 does, so I think we should leave
the editor code as is to be compatible with that.
It's a little weird that zero ("do the default for the platform") now use
1 in editor and 2 in selection but it should work also for users that have
explicitly changed the pref to 1 or 2 (they should see no change).

OK, let's see what break this time, now with Linux also using 2 in selection.
https://tbpl.mozilla.org/?tree=Try&rev=e813a1025a29

Comment 8

[Mats Palmgren (inactive)]

Attachment: fix, v2

Change default selection behavior also on Linux, so now it's the same
on all platforms.  Don't touch editor/ since it only deals with
"word delete" behavior which we don't want to change.
Update the documentation in all.js.

Comment 9

[Mats Palmgren (inactive)]

Attachment: fix, v3

It turns out the failing test has a bug.  The use of Cmd+LEFT and Cmd+UP
both makes aKeycode == 36 (DOM_VK_HOME) in this code:
http://hg.mozilla.org/mozilla-central/annotate/ee5ca214e87c/layout/generic/nsSelection.cpp#l787
so this test enters the block at line 795-827 and falls straight through
without matching any 'case' value.

Now that Linux/Windows also has caretStyle == 2 they will enter this
block and match DOM_VK_UP/LEFT which affects the test.

What the test really wants to do is move the caret to the beginning
of a <input> or <textarea> with a single line.  We should use DOM_VK_HOME
for that, except on OSX where we continue to use Cmd+LEFT to generate
the DOM_VK_HOME.

Try is green on all platforms:
https://tbpl.mozilla.org/?tree=Try&rev=79f4f06344be

Comment 10

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9a09523eb5dd

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9a09523eb5dd