To repro: 1. Pick your favorite editable region (rich text, text area, text input) 2. Enter some text (like "foo bar baz") 3. Double inside "bar" to select the word 4. shift + left arrow to move the selection Result: Sometimes, moves the start of the selection one space to the left, expanding the selection by one character. Other times, collapses the selection down to the middle of the word where you had originally double clicked, and then moves one space from there, giving a selection with a single char selected. I can't really figure out how to repro one way or another, but they both happen consistently. Expected Result: First, consistency. Second, both IE and FF will move the end of the selection, rather than the start. Would be nice to be consistent with them. (Unless you are in left to right mode, where it moves the start). This info is all based off of Windows - Chrome, Safari 3.1, IE 7, FF 3. I'm told that the Safari Mac behavior is slightly different.
The Mac behavior is that if the first directional key after the double-click-to-select is a left arrow the selection expands to the left, if the first is a right arrow, it expands to the right. Windows always expands/contracts the selection from the right hand side. Then again, they also select the space following the word after a double click too. :(
Windows will expand/contract the selection from the left hand side if the text is right-to-left.
I could reproduce the inconsistent behavior on the Mac (both shipping WebKit and ToT). Looks like it depends on whether the mouse pointer moved while the mouse button was pressed. It is probably best to track this bug separately from any platform-specific behavior adjustments.
I cannot reproduce this bug anymore on WebKit ToT or Safari 5 on Mac OS X.
I also canot reproduce this inconsistency any more (testing with Safari 5.1 on Mac).