Caret position after updating value IDL attribute of unfocused INPUT element is incompatible

Source/core/html/forms/TextFieldInputType.cpp

Index: Source/core/html/forms/TextFieldInputType.cpp
diff --git a/Source/core/html/forms/TextFieldInputType.cpp b/Source/core/html/forms/TextFieldInputType.cpp
index 1b78abe81c6802df9dd34458a9f75859217cdbb0..a5b1aa72825f4014b75a7f8ae4e96d491c76d210 100644
--- a/Source/core/html/forms/TextFieldInputType.cpp
+++ b/Source/core/html/forms/TextFieldInputType.cpp
@@ -160,8 +160,6 @@ void TextFieldInputType::setValue(const String& sanitizedValue, bool valueChange
     unsigned max = visibleValue().length();
     if (input->focused())
         input->setSelectionRange(max, max);
-    else
-        input->cacheSelectionInResponseToSetValue(max);

[tkent, 2014/04/28 00:33:40]

What happens if selectionStart=selectionEnd=3 before updating the value, and the
new value length is 1?  How other browser work?

[harpreet.sk, 2014/04/28 16:07:55]

In the above case the caret is place at end of text ie at position 1.
I checked in firefox also, it behaves in same manner.

But there is a problem for some cases say for example 
selectionStart = 3 selectionEnd=5 and new value length is greater than 5. In
that case it should select the text ( it is the behaviour of firefox) but it is
not happening as the selectionStart and selectionEnd is not getting store in
m_cachedSelectionStart/m_cachedSelectionEnd properly so it is not selecting
text. 

Actually it is a bug that blink does not respect input.selectionStart and
input.selectionEnd. I filed the bug for the same: 
Issue 367736: Blink does not respect input.selectionStart and input.selectionEnd
for some cases

I have also uploaded the patch for the same. That patch will also solve the
current bug.

https://codereview.chromium.org/258063005

 
     if (!valueChanged)
         return;