Bug 12593 - REGRESSION: Reversed drag-select behavior in text boxes
Summary: REGRESSION: Reversed drag-select behavior in text boxes
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Adele Peterson
URL:
Keywords: InRadar
: 12610 19466 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-02-04 11:02 PST by Maciej Stachowiak
Modified: 2011-03-08 14:22 PST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Stachowiak 2007-02-04 11:02:43 PST
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>
Comment 1 Daniele Metilli 2007-02-05 10:50:27 PST
*** Bug 12610 has been marked as a duplicate of this bug. ***
Comment 2 Darin Adler 2007-02-06 14:50:44 PST
This might be a duplicate of bug 7774.
Comment 3 mitz 2008-06-10 14:26:07 PDT
*** Bug 19466 has been marked as a duplicate of this bug. ***
Comment 4 mkterra 2009-03-02 19:09:42 PST
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!
Comment 5 mkterra 2009-06-02 02:04:08 PDT
(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 :(
Comment 6 Cngevpxhaqrefpber 2011-03-08 14:22:57 PST
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. :)