Summary: | REGRESSION: Reversed drag-select behavior in text boxes | ||
---|---|---|---|
Product: | WebKit | Reporter: | Maciej Stachowiak <mjs> |
Component: | Forms | Assignee: | Adele Peterson <adele> |
Status: | ASSIGNED --- | ||
Severity: | Normal | CC: | alexander.steitz, Cngevpxhaqrefpber, daniele.metilli, dev+webkit, emacemac7, jonathon, mitz |
Priority: | P1 | Keywords: | InRadar |
Version: | 420+ | ||
Hardware: | Mac | ||
OS: | OS X 10.4 |
Description
Maciej Stachowiak
2007-02-04 11:02:43 PST
*** Bug 12610 has been marked as a duplicate of this bug. *** *** 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 :( 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. :) |