RESOLVED WORKSFORME 23794
Double click to select word + arrow key movement inconsistent 
https://bugs.webkit.org/show_bug.cgi?id=23794
Summary Double click to select word + arrow key movement inconsistent
Julie Parent
Reported 2009-02-06 12:37:31 PST
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.
Attachments
Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2009-02-06 13:42:17 PST
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. :(
Ojan Vafai
Comment 2 2009-02-06 13:43:52 PST
Windows will expand/contract the selection from the left hand side if the text is right-to-left.
Alexey Proskuryakov
Comment 3 2009-02-07 04:12:20 PST
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.
Ryosuke Niwa
Comment 4 2011-08-15 10:55:53 PDT
I cannot reproduce this bug anymore on WebKit ToT or Safari 5 on Mac OS X.
Alexey Proskuryakov
Comment 5 2011-08-15 15:23:52 PDT
I also canot reproduce this inconsistency any more (testing with Safari 5.1 on Mac).
Note You need to log in before you can comment on or make changes to this bug.