setSelectionRange should set selection without validation

setSelectionRange should set selection without validation
https://bugs.webkit.org/show_bug.cgi?id=128949

Reviewed by Enrica Casucci.

Source/WebCore:

Since positionForIndex in HTMLTextFormControlElement always returns a candidate Position, we don't have to
validate selection in setSelectionRange.

Also fixed various bugs uncovered by this change.

This patch also fixes fast/forms/input-select-webkit-user-select-none.html, which used to assert wrong outcome
so that WebKit's behavior matches that of Chrome and Firefox.

Test: fast/forms/input-select-webkit-user-select-none.html

* dom/Position.h:
(WebCore::positionInParentBeforeNode): This function had a bug that when node is a child of the shadow root
it would return a null Position. Allow a position anchored inside a shadow root.
(WebCore::positionInParentAfterNode): Ditto.

* editing/FrameSelection.cpp:
(WebCore::FrameSelection::moveWithoutValidationTo): Renamed from moveTo and avoided selection validation.
* editing/FrameSelection.h:

* editing/htmlediting.cpp:
(WebCore::updatePositionForNodeRemoval): Fixed the bug that this function doesn't update positions before
or after children even if the shadow host of the anchor node is getting removed. Move the position before
the shadow host to be removed in both situations.

* html/HTMLTextFormControlElement.cpp:
(WebCore::HTMLTextFormControlElement::setSelectionRange): moveTo is renamed to moveWithoutValidationTo.
(WebCore::HTMLTextFormControlElement::selectionChanged): Check if the cached selection offsets are different
in lieu of FrameSelection::isRange() since they're equivalent here.
(WebCore::positionForIndex): Return the position inside or after the last br when there is one to match
the canonicalization algorithm we have. It's probably harmless to return the last position in the inner text
element anyways since most of our codebase supports that but this would avoid having to rebaseline dozens
of tests and reduces the risk of this patch.

LayoutTests:

Fixed input-select-webkit-user-select-none.html which was erroneously asserting selectionStart and selectionEnd
of a text field to be zero when it has -webkit-user-select: none. This doesn't not match behaviors of Chrome
and Firefox. They both retain the programatically set selection offsets since such style should not bleed into
the shadow DOM of the text field in the first place.

New behavior matches the latest Firefox and Chrome although we still have the bug that user cannot select text
inside such a text field.

Also modernized LayoutTests/editing/selection/5497643.html to make the expected results more readable and made
the test more robust against changes in the node index of textarea element.

* editing/selection/5497643-expected.txt: See above.
* editing/selection/5497643.html:
* fast/forms/input-select-webkit-user-select-none-expected.txt: See above.
* fast/forms/input-select-webkit-user-select-none.html:
* editing/deleting/delete-ligature-001-expected.txt: Progression in the editing delegate callbacks dumps.
Now we set selection directly into the text node inside the inner text element.
* platform/mac/platform/mac/editing/spelling/autocorrection-at-beginning-of-word-1-expected.txt: Ditto.
* platform/mac/platform/mac/editing/spelling/autocorrection-at-beginning-of-word-2-expected.txt: Ditto.
* platform/mac-mountainlion/platform/mac/editing/spelling/autocorrection-at-beginning-of-word-1-expected.txt:
Removed.
* platform/mac-mountainlion/platform/mac/editing/spelling/autocorrection-at-beginning-of-word-2-expected.txt:
Removed.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@164316 268f45cc-cd09-0410-ab3c-d52691b4dbfc