Bug 8116 – REGRESSION: Selection issues occur when dragging from left to right in native text fields

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Chris Petersen]

I'm noticing when dragging left to right the selection while become invalid when I-beam cursor outside of the text field.

Steps to reproduce:

1) With TOT Webkit, open attached test case "input_selection_test.html".
2) Place caret before "T" in "This".
3) Mouse down and drag over "This is a test". Move cursor outside the right edge of text field.
4) Notice the selection becomes invalid as you drag outside of text field
5) Again place caret before "T" in "This".
6) Drag over "This is a" then move cursor to the bottom of text first
7) Move cursor outside of the text field and again selection becomes invalid

Note: If I place caret at the END of the text field and drag a selection ( from right to left), the selection remains intact if I move the cursor outside of field.

[Chris Petersen]

Created attachment 7430 [details]
Sample input field

[Chris Petersen]

This issue is covered in <rdar://problem/4499022>

[Chris Petersen]

My original description should have said:

I'm noticing when dragging left to right, the selection will become invalid
when I-beam cursor moves outside of the text field.

[Darin Adler]

Bug 8134 describes almost exactly the same thing.

[Maciej Stachowiak]

These are all text field regressions so they should all be P1.

[Darin Adler]

I'll take a look at these.

[Darin Adler]

Something's going wrong in Selection::adjustForEditableContent, which is supposed to handle things like this.

[Darin Adler]

The main problem seems to be the call to Range::compareBoundaryPoints inside Selection::validate. This won't handle selection endpoints that are inside the shadow DOM. That's what we need to fix.

[Darin Adler]

I need to talk to Adele and Hyatt about this one. It's a side effect of the shadow DOM not having a parent that points to the real DOM. I understand why the real DOM can't point down into the shadow DOM, but I don't understand why it's a problem to have the shadow DOM pointing back up to the real one. To fix this, I'm having to change tons of places to call shadowParentNode after calling parentNode, and I think that might not be the right way to go.

[Darin Adler]

Turns out my fix for bug 8134 does fix the test case attached here.