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

Source/core/html/forms/TextFieldInputType.cpp

 /*
  * Copyright (C) 2010 Google Inc. All rights reserved.
  * Copyright (C) 2011 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
@@ skipping 142 matching lines @@
     // We don't ask InputType::setValue to dispatch events because
     // TextFieldInputType dispatches events different way from InputType.
     InputType::setValue(sanitizedValue, valueChanged, DispatchNoEvent);
 
     if (valueChanged)
         input->updateView();
 
     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;
 
     switch (eventBehavior) {
     case DispatchChangeEvent:
         // If the user is still editing this field, dispatch an input event rather than a change event.
         // The change event will be dispatched when editing finishes.
         if (input->focused())
             input->dispatchFormControlInputEvent();
@@ skipping 390 matching lines @@
     return shouldSpinButtonRespondToMouseEvents() && element().focused();
 }
 
 void TextFieldInputType::spinButtonDidReleaseMouseCapture(SpinButtonElement::EventDispatch eventDispatch)
 {
     if (eventDispatch == SpinButtonElement::EventDispatchAllowed)
         element().dispatchFormControlChangeEvent();
 }
 
 } // namespace WebCore