Bug 12593 – REGRESSION: Reversed drag-select behavior in text boxes

• Status: ASSIGNED
• Component: Forms

[Maciej Stachowiak]

2006-08-21 17:15:41 Ast Moore:
Safari shows reversed drag-select behavior in text boxes: bottom left, top right. See screen capture. Text selection in Google's search filed is reversed. Text selection in the address bar is working correctly.
(see attached screen capture)



'Safari Drag-Select Bug.mov' was successfully uploaded

2006-08-21 17:15:41 Ast Moore:
Please assign to Developer ADCBugs for further communications with the developer.

2006-08-22 19:09:41 Stephanie Lewis:
This worked in Safari 2.0.4 and is broken in Leopard 9A427

2006-08-29 10:32:32 Alice Liu:
Safari BRB Reviewed 

2006-12-15 19:32:22 Stephanie Lewis:
Still occurs in Leopard 9A325

2006-12-18 11:12:05 Adele Peterson:
This happens because when you drag to the top right, that position is actually before the text field in the DOM, so the selection code selects all content in the text field before the caret.  In the bottom-left case, that mouse position is after the text field in the DOM.  So the selection code behaves as if it were going to select all of the content in between the caret and the new mouse position-- but it stops short at the text field boundary.

I'm not sure what the right fix is for this.  Maybe adjustForEditableContent would need to be more aware of this case.

<rdar://problem/4692735>

[Daniele Metilli]

*** Bug 12610 has been marked as a duplicate of this bug. ***

[Darin Adler]

This might be a duplicate of bug 7774.

*** Bug 19466 has been marked as a duplicate of this bug. ***

This bug shows up in Google Chrome too, due to its use of Webkit.  More info here, with some animated gifs:
http://code.google.com/p/chromium/issues/detail?id=1311

It's been marked as an Upstream issue, so I hope it can be fixed here!

(In reply to comment #0)
> 2006-12-18 11:12:05 Adele Peterson:
> This happens because when you drag to the top right, that position is actually
> before the text field in the DOM, so the selection code selects all content in
> the text field before the caret.  In the bottom-left case, that mouse position
> is after the text field in the DOM.  So the selection code behaves as if it
> were going to select all of the content in between the caret and the new mouse
> position-- but it stops short at the text field boundary.
> 
> I'm not sure what the right fix is for this.  Maybe adjustForEditableContent
> would need to be more aware of this case.
> 
> <rdar://problem/4692735>
> 

It looks like the selection code's been reorganized since 2006, so adjustForEditableContent is now called adjustSelectionToAvoidCrossingEditingBoundaries:
http://trac.webkit.org/browser/trunk/WebCore/editing/VisibleSelection.cpp

But the actual code's the same, so the selection behavior is still bugged up :(

[Cngevpxhaqrefpber]

There's probably no need for me to mention it, but I can confirm that this issue exists on Windows as well.

Anyway, would love to see this fixed, it's super annoying. :)