INPUT/TEXTAREA value setter with the same value should not change text selection

[tkent-google]

https://html.spec.whatwg.org/multipage/forms.html#dom-input-value

and then, if the element has a text entry cursor position, should move the text entry cursor position to the end of the text control, unselecting any selected text and resetting the selection direction to none.

https://html.spec.whatwg.org/multipage/forms.html#dom-textarea-value

on setting, it must set the element's raw value to the new value, set the element's dirty value flag to true, and should then move the text entry cursor position to the end of the text control, unselecting any selected text and resetting the selection direction to none.

Value setter for INPUT and TEXTAREA update text selection unconditionally.

As for TEXTAREA, Chrome, Edge, Firefox and Safari do nothing if new value is same as the old value.
As for INPUT. Chrome and Safari update text selection, and Edge and Firefox do nothing.

I propose updating the specification so that these value setters do nothing if new value is same as old value. I'll update Chrome implementation if the specification is changed.

[domenic]

This sounds reasonable. Any thoughts, @rniwa?

[rniwa]

Seems reasonable to me. There's a big question regarding how the general selection API and selection in text fields are associated though: w3c/selection-api#83

[bzbarsky]

I implemented this in Firefox today, and immediately ran into regression test failures on React apps.

React, in postMountWrapper for <input>, does node.value = node.value. See https://github.com/facebook/react/blob/7bf686b76f20eca07f0abef1bf6a0f0380b0c3f2/src/renderers/dom/stack/client/wrappers/ReactDOMInput.js#L259

So if in a React app you focus an input that function was called on, the cursor will be at the end. With the changes for this issue it will be in the beginning. A minimal React-less testcase that is currently interoperable across at least Chrome, Firefox, and Safari (no Windows on hand right this second to test Edge) and changes behavior with the proposed spec changes:

<input value="text">
<script>
  var i = document.querySelector("input");
  i.value = i.value;
  i.focus();
</script>

I am sufficiently worried about web compat fallout here that I'm suspending work on this in Firefox for the moment.

[domenic]

Thanks. It looks like in Edge the cursor stays at the beginning.

I'm hopeful @tkent-google is still willing to try this in Chrome; I think examples like the one you mention will probably get better UX, not worse, as moving the cursor seems like an unintended side effect of that line in React (which just intends to set the dirty value flag, per the comment in the code above that line).

If we for some reason can't get this working for input, I imagine we'll still want to do it for textarea, given that the majority of browsers do nothing in that case.

[tkent-google]

I still think changing the INPUT value setter behavior is ok.
ReactDOMTextarea.js doesn't set selectionStart, selectionEnd, etc. So behavior of ReactDOMInput.js and ReactDOMInput.js will be consistent.

[domenic]

Great :). Hopefully we can ship in Chrome and then Boris can feel more comfortable about the web-compat impact for shipping in Firefox.

[bzbarsky]

So behavior of ReactDOMInput.js and ReactDOMInput.js will be consistent.

Was one of those meant to be "ReactDOMTextarea.js"?

[tkent-google]

Was one of those meant to be "ReactDOMTextarea.js"?

Oh, Yes :)