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

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

The caret position after updating value IDL attribute of unfocused INPUT
element is incompatible. When the value IDL attribute is updated of unfocused
INPUT element the caret moves at the end but other browser move the caret at the
beginning of the value. The other browsers move the caret to the end of the value
only if the INPUT is focused. This patch removes this bug by removing the line
which set the cached selection start and end with the length of the value.

BUG=133242

[harpreet.sk, 2014-04-27 14:31:21]

Please take a look. If it is ok then i will add the layout test for the same.

[tkent, 2014-04-28 00:33:39]

Please add a test

https://codereview.chromium.org/258953002/diff/1/Source/core/html/forms/TextF...
File Source/core/html/forms/TextFieldInputType.cpp (left):

https://codereview.chromium.org/258953002/diff/1/Source/core/html/forms/TextF...
Source/core/html/forms/TextFieldInputType.cpp:164:
input->cacheSelectionInResponseToSetValue(max);
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:54]

https://codereview.chromium.org/258953002/diff/1/Source/core/html/forms/TextF...
File Source/core/html/forms/TextFieldInputType.cpp (left):

https://codereview.chromium.org/258953002/diff/1/Source/core/html/forms/TextF...
Source/core/html/forms/TextFieldInputType.cpp:164:
input->cacheSelectionInResponseToSetValue(max);
On 2014/04/28 00:33:40, tkent wrote:
> What happens if selectionStart=selectionEnd=3 before updating the value, and
the
> new value length is 1?  How other browser work?


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

[harpreet.sk, 2014-07-08 08:51:02]

This bug has been solved in the following revision
https://src.chromium.org/viewvc/blink?view=rev&revision=177651

Hence closing this issue.