Controlled input allows dot #9561
Comments
|
This is interesting. The reason for this is because 2. or 2.0 (which is also allowed) equals to 2. Casting the value to a String first before doing the comparison could fix this problem, however it could be also intended behavior. |
|
But note that the type of the input is "text" and such an input will always give you a string and "2." is by no means equal to either "2" or 2 (number). Also "2.000000000000" is very different from 2. |
|
I'm not sure what you mean by casting the value to a String, since the input (with type "text") always gives you a string. |
|
Think the actual problem is caused by this check |
|
Yes, |
This is about the |
|
@nhunzaker what was the reason for using loose equality checks for |
|
I believe this was a relic of dealing with edge cases on number inputs. In short: if we touch the value property of number inputs whatsoever, Chrome/Safari will do unexpected things like drop trailing decimal places, clear out invalid input, etc. So this needs to go. When I added the condition to specifically check for the |
This commit removes a check I added when working on number input issues where we perform a loose check on an input's value before we assign it. This prevented controlled text inputs from disallowing numeric text entry. I also added a DOM fixture text case. Related issues: facebook#9561 (comment)
This commit removes a check I added when working on number input issues where we perform a loose check on an input's value before we assign it. This prevented controlled text inputs from disallowing numeric text entry. I also added a DOM fixture text case. Related issues: facebook#9561 (comment)
|
I sent out a PR here: #9584 Sorry for the trouble. |
…issue. (#9584) * Remove loose check when assigning non-number inputs This commit removes a check I added when working on number input issues where we perform a loose check on an input's value before we assign it. This prevented controlled text inputs from disallowing numeric text entry. I also added a DOM fixture text case. Related issues: #9561 (comment) * Use strict equality as a guard before assigning input.value This commit adds back the guard around assigning the value property to an input, however it does it using a strict equals. This prevents validated inputs, like emails and urls from losing the cursor position. It also adds associated test fixtures. * Add copy command after build for interup with surge.sh
…issue. (#9584) * Remove loose check when assigning non-number inputs This commit removes a check I added when working on number input issues where we perform a loose check on an input's value before we assign it. This prevented controlled text inputs from disallowing numeric text entry. I also added a DOM fixture text case. Related issues: #9561 (comment) * Use strict equality as a guard before assigning input.value This commit adds back the guard around assigning the value property to an input, however it does it using a strict equals. This prevents validated inputs, like emails and urls from losing the cursor position. It also adds associated test fixtures. * Add copy command after build for interup with surge.sh
|
#9584 is merged now, issue can be closed 👍 |
…issue. (facebook#9584) * Remove loose check when assigning non-number inputs This commit removes a check I added when working on number input issues where we perform a loose check on an input's value before we assign it. This prevented controlled text inputs from disallowing numeric text entry. I also added a DOM fixture text case. Related issues: facebook#9561 (comment) * Use strict equality as a guard before assigning input.value This commit adds back the guard around assigning the value property to an input, however it does it using a strict equals. This prevents validated inputs, like emails and urls from losing the cursor position. It also adds associated test fixtures. * Add copy command after build for interup with surge.sh
Do you want to request a feature or report a bug?
bug
What is the current behavior?
React allows a dot in a controlled input that doesn't allow changing the value, if the value set as a prop is a number. If it's a string the issue is not present.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/84v837e9/).
https://jsfiddle.net/84v837e9/23/
In this example the first input allows a dot, even though the code doesn't allow changes. The second input doesn't allow the dot.
What is the expected behavior?
The dot shouldn't be allowed.
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
version 15.5.4, Chrome and Firefox (see the jsfiddle example)
The text was updated successfully, but these errors were encountered: