Created attachment 70547 [details] IE8 behavior (correct) Scenario: Multi-row textarea element (paragraph style text input box). Populated with multiple lines of text. Actions to reproduce: Highlight a line of text in the middle of the paragraph, and drag cursor outside of text input box boundary (either left or right). Desired outcome (Firefox, IE8 behavior): Highlight stops (vertically) at the Y position of your mouse cursor, outside of the textarea boundaries. Webkit behaviour: Highlights entire text box from the initial line to the beginning (if exited left) or the end (if exited right), regardless of where your mouse cursor is vertically. Attached 3 images to illustrate for comparison (Firefox, IE8 and Chrome behaviors)
Created attachment 70548 [details] Firefox 3.6 behavior (correct)
Created attachment 70549 [details] Chrome / WebKit behavior
In each the images, my mouse is to the left of the word "multiline", just outside of the textarea boundary
CCing some text editing folks for triage
I always assumed this was just a Mac-ism, but it seems that TextEdit does the IE8/FF3.6 behavior. So, I'm less confident now that this was intentional.
Julie/Ojan/Ryosuke, is there any chance we could try and fix this some time soon? There's also a related issue here where dragging out of the box vertically highlights from the selection beginning to the start or end of the text (which seems wrong for single-line textfields at least) but which way it goes flipflops in strange ways as you move the mouse up and down (e.g. as you're dragging the mouse down it will highlight to end, then for 2 pixels flip to highlighting to start, then flip back to highlighting to end). I don't know if these issues are on file elsewhere.
(In reply to comment #6) > Julie/Ojan/Ryosuke, is there any chance we could try and fix this some time soon? > > There's also a related issue here where dragging out of the box vertically highlights from the selection beginning to the start or end of the text (which seems wrong for single-line textfields at least) but which way it goes flipflops in strange ways as you move the mouse up and down (e.g. as you're dragging the mouse down it will highlight to end, then for 2 pixels flip to highlighting to start, then flip back to highlighting to end). I don't know if these issues are on file elsewhere. Let me take a look later.
Created attachment 78641 [details] DRT demo This demo only works in DRT.
Fixing this bug requires significant amount of work. Right now, EventHandler::updateSelectionForMouseDrag sets setExtent regardless of where targetPosition is and VisibleSelection::adjustSelectionToAvoidCrossingEditingBoundaries adjusts the extent to the first or the last position in the editable region when the extent's root editable element and base's root editable element are different. However, adjustSelectionToAvoidCrossingEditingBoundaries doesn't know how the extent was set so there's no way we can "fix" adjustSelectionToAvoidCrossingEditingBoundaries to deal with this situation. So we'll need to have EventHandler::updateSelectionForMouseDrag detect that we're in a different editable root and do the correct thing there. But just checking the root editable elements isn't sufficient because an editable element may also contain non-editable elements and we can't simply assume that targetPosition we're getting is outside of base's root editable element.
I vaguely recall seeing an earlier bug on this, but I can't find it.
Unassigning myself since I don't intend to work on this bug anytime soon.