INPUT/TEXTAREA elements: Fix incorrect selectionStart/selectionEnd values after blur.

third_party/WebKit/Source/core/editing/FrameSelection.cpp

Index: third_party/WebKit/Source/core/editing/FrameSelection.cpp
diff --git a/third_party/WebKit/Source/core/editing/FrameSelection.cpp b/third_party/WebKit/Source/core/editing/FrameSelection.cpp
index 54daa8e576628fe5f714472a03123bd96cdba958..2da08fdc929c379508ec88acf23a25f2786b6e2e 100644
--- a/third_party/WebKit/Source/core/editing/FrameSelection.cpp
+++ b/third_party/WebKit/Source/core/editing/FrameSelection.cpp
@@ -218,8 +218,14 @@ bool FrameSelection::SetSelectionDeprecated(
 
   const SelectionInDOMTree old_selection_in_dom_tree =
       selection_editor_->GetSelectionInDOMTree();
-  if (old_selection_in_dom_tree == new_selection)
+  if (old_selection_in_dom_tree == new_selection) {
+    // Even if DOM representation of text selection is not changed,
+    // selectionStart / selectionEnd IDL attributes of a text control can be
+    // changed.

[yoichio, 2017/05/12 01:54:00]

Could you explain why?

[tkent, 2017/05/12 02:01:01]

e.g.

DIV id=inner-editor
  #text "line-1\n"
  #text "line-2\n"

The caret is on offset=0 of the second Text node, and type Backspace will make
the DOM:

DIV id=inner-editor
  #text "line-1"
  #text "line-2\n"

but the caret position is still offset=0 of the second Text node.

Patch Set 3 has a comment on this.

+    NotifyTextControlOfSelectionChange(

[yosin_UTC9, 2017/05/12 01:37:00]

Can we update cached selection in "webkitEditableContentChanged" event handler
in
TextControlElement::DefaultEventHandler()?

void TextControlElement::DefaultEventHandler(Event* event) {
  if (event->type() == EventTypeNames::webkitEditableContentChanged &&
      GetLayoutObject() && GetLayoutObject()->IsTextControl()) {
    last_change_was_user_edit_ = !GetDocument().IsRunningExecCommand();
    SubtreeHasChanged();
    return;
  }
  ...

It seems SubtreeHasChange() is the right place to sync cached selection.

[tkent, 2017/05/12 02:01:01]

Patch Set 3 follows it.

Yes, handling in TextControl is better than adding notification to the
no-selection-change path.

+        SelectionOptionsToUserTriggered(options));
     return false;
+  }
   selection_editor_->SetSelection(new_selection);
   ScheduleVisualUpdateForPaintInvalidationIfNeeded();
 
@@ -269,7 +275,7 @@ void FrameSelection::DidSetSelectionDeprecated(SetSelectionOptions options,
   }
 
   EUserTriggered user_triggered = SelectionOptionsToUserTriggered(options);
-  NotifyLayoutObjectOfSelectionChange(user_triggered);
+  NotifyTextControlOfSelectionChange(user_triggered);
   if (user_triggered == kUserTriggered) {
     ScrollAlignment alignment;
 
@@ -708,7 +714,7 @@ void FrameSelection::SelectAll() {
                    .SetIsHandleVisible(IsHandleVisible())
                    .Build());
   SelectFrameElementInParentIfFullySelected();
-  NotifyLayoutObjectOfSelectionChange(kUserTriggered);
+  NotifyTextControlOfSelectionChange(kUserTriggered);
 }
 
 bool FrameSelection::SetSelectedRange(const EphemeralRange& range,
@@ -840,7 +846,7 @@ void FrameSelection::UpdateAppearance() {
   layout_selection_->SetHasPendingSelection();
 }
 
-void FrameSelection::NotifyLayoutObjectOfSelectionChange(
+void FrameSelection::NotifyTextControlOfSelectionChange(
     EUserTriggered user_triggered) {
   TextControlElement* text_control =
       EnclosingTextControl(GetSelectionInDOMTree().Base());