Do you want to request a feature or report a bug?
bug
What is the current behavior?
email input doesn't control for whitespace // possible variation on Issue 6368; however, 6368 shows up at 15.0.0 this bug shows up at 15.2
If the current behavior is a bug, demo
no bug in React 15.0.0
no bug in React 15.1.0
bug on React 15.2
React~15 fiddle
bug on React 16
React~16 fiddle
What is the expected behavior?
When a user presses down the backspace key and holds it, all values in the input are removed, including the whitespaces
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
Works on 15.1.0
bug at >= 15.2.0
testing on Chrome 63
MacOs Sierra 10.12
@gaearon Is this a bug that a newbie to React contributing can take? If so, I would like to take it.
@binygal its probably not a very newbie friendly bug (if it's a bug) :/ you are welcome to take a look but lets identify what's going on first before we try and fix anything
So the reason it worked in 15.1.0 is that we used to use DOMPropertyOperations.setValueForProperty which didn't update the value property unless the value has changed. Since email inputs always trim the input value "foo bar " would be reported as "foo bar", which would be updated in state by the onChange handler, and it wouldn't update node.value
In 16.2.0 the mutation method for value is updating the attribute regardless of whether the value has changed, which forces the input to the trimmed value, which breaks the cursor position and we see this strange behavior.
On master we no longer use mutation methods and rely on setting defaultValue. Testing with a build from master we have the same problem with #11534 since defaultValue will not match the trimmed value.
It's a hard problem (as mentioned in #6368) since the email input is trying to be "helpful" and trim what it considers invalid characters. We could possibly add some exceptions for updating defaultValue for email inputs, but it might be messy.
We could also stop trying to have value attribute match the properties in 17. Would that solve this issue?
Yeah, I believe we've talked about doing it in the next major a few times. We should probably open an issue to centralize the discussion.
When backspace, will fire topKeyDown, topInput, topKeyUp three event. I think the problem is the topInput event.
Thought I was hitting something similar here. Same symptom (no backspace) but I had mistakenly assigned the input type to "string" instead of "text" in case that's related or interesting.
Most helpful comment
So the reason it worked in
15.1.0is that we used to useDOMPropertyOperations.setValueForPropertywhich didn't update thevalueproperty unless the value has changed. Since email inputs always trim the input value"foo bar "would be reported as"foo bar", which would be updated in state by theonChangehandler, and it wouldn't updatenode.valueIn
16.2.0the mutation method forvalueis updating the attribute regardless of whether the value has changed, which forces the input to the trimmed value, which breaks the cursor position and we see this strange behavior.On master we no longer use mutation methods and rely on setting
defaultValue. Testing with a build frommasterwe have the same problem with #11534 sincedefaultValuewill not match the trimmed value.It's a hard problem (as mentioned in #6368) since the email input is trying to be "helpful" and trim what it considers invalid characters. We could possibly add some exceptions for updating
defaultValuefor email inputs, but it might be messy.