Visible text changes when assigning to input.defaultValue

[josepharhar]

In Chrome and Safari, but not Firefox, sanitization will apply in-place for number and email inputs when modifying the value attribute, via any of setAttribute('value', ...), removeAttribute('value'), and defaultValue = ....
In React, defaultValue is assigned every time the input event is fired on the input element in order to make the value attribute reflect what the controlling react component is. I made a minimal example of how this works here: https://value-attribute.glitch.me/

This works fine, but when the user enters something which would be modified by sanitization, the visible text will be swapped out and selection reset while the user is typing. You can see this behavior by going to my minimal example page above and typing something like " user@example.com" in the email input or "12e3" into the number input.
React has made workarounds for this behavior for number inputs by delaying assigning to defaultValue until the blur event, but they have not done so for email inputs and it has caused many issues in react:

• Sometimes controlled email inputs break in Chrome due to punycoding facebook/react#14356
• Input type email bug facebook/react#14168
• Field type="email" with multiple attribute cursor jumps to start facebook/react#15418
• Cursor jumps with controlled input with email type facebook/react#14551

I am guessing this behavior exists in chrome and safari to make it so that when the default value from the value attribute is used it is sanitized, but in this case the value attribute is not actually being used at all. I proposed adding the input.rawValue property to address this problem, but I think that changing this behavior to only change the visible text when we are actually using the default value would be a better fix, especially since Firefox already has the desired behavior. I made a WIP patch to do this in chrome here.

Is this behavior specced? Should it be specced?

cc @tkent-google @domenic @mfreed7

[tkent-google]

only change the visible text when we are actually using the default value would be a better fix

It seems the current Chrome/Safari behavior looks just an implementation bug, and we don't need to discuss it in WHATWG.

[josepharhar]

Sweet! Thanks for the clarification!

[annevk]

Please do add web-platform-tests for this if there aren't any. E.g., this could be tested with reference tests I suspect.

[josepharhar]

I like the reftest idea, I think its perfect.
Unfortunately I couldn't get test_driver.Actions() to type into the input elements for me...

[annevk]

@josepharhar file an issue at https://github.com/web-platform-tests/wpt/issues/new with some steps to reproduce? I'm sure they can help you.

[josepharhar]

Coming back to this, I finally got the wpt to work, I just had to use test_driver.send_keys instead of test_driver.Actions. The fix and wpt will be merged soon