Remove loose check on non-number controlled inputs. Fix trailing dot issue. #9584
Conversation
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)
|
Maybe unrelated, but why does editing "controlled email" in the middle throw me to the end of the input? |
|
Same question for URLs and passwords. I'm on latest stable Chrome on OSX. |
|
It's because it's now alway setting @nhunzaker could we just change the loose equality check to a strict one? |
|
Haha, first instance of fixtures saving us? 😄 |
|
It's already paying off 😄 @nhunzaker thanks for deploying the fixtures by the way, that really makes it easier to review. It would be cool if we could include some instructions on doing that for the more ambitious contributors. |
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.
nhunzaker
force-pushed
the
nh-controlled-text-input-numbers
branch
from
b0df2fc
to
d421181
Compare
|
@aweary Good thought. For the time being, I've just added an extra bit to the build script to copy over Good call too! The strict equality check totally did it. http://nh-controlled-text-input-numbers.surge.sh/text-inputs |
|
@aweary Mind doing a full review? |
|
Do you want to take this into 15.6? |
|
@gaearon I was just typing that same question! 😄 I think including it in the next 15 release is a good idea, since it fixes a regression. What needs to be done to make sure this is included in 15.6? |
|
@flarnie What are your thoughts, would this be difficult? Seems like it’s a fix we want to get in (since it fixes a 15.5 regression). |
|
I agree - this would be good to get into the 15.6 release. I'll cherry-pick it. Also "We need to include a requestAnimationFrame polyfill to test in older browsers, but I think we can do that in a follow-up." - I'm not seeing any use of 'requestAnimationFrame' in these changes, is there still a need for a polyfill there? |
I didn't want to merge until I was clear on how including this in 15.6 was handled.
Nothing specific to these changes, Fiber requires |
| renderControlled = (type) => { | ||
| let id = `controlled_${type}`; | ||
| <TestCase.ExpectedResult> | ||
| The text field's value should not update. |
There was a problem hiding this comment.
Might change to {`The text field's value should not update.`} to make syntax highlighters happy.
…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
**what is the change?:** This seems useful, even for this short-lived branch, and some commits we cherry-picked were making updates to it. So we just pulled the fixture in from master. **why make this change?:** To bring things into a bit more consistency with master. **test plan:** Manually tested the fixture - things seem to work. **issue:** None - but related to cherry-picking facebook#9584
Updating the change log~ :) **issue:** facebook#9398
This is a follow-up on #9584 (comment). There is no need to assign the value property of an input if the value property of the React component changes types, but stringifies to the same value. For example: ```javascript DOM.render(<input value="true" />, el) DOM.render(<input value={true} />, el) ``` In this case, the assignment to `input.value` will always be cast to the string "true". There is no need to perform this assignment. Particularly when we already cast the value to a string later: ```javascript // Cast `value` to a string to ensure the value is set correctly. While // browsers typically do this as necessary, jsdom doesn't. node.value = '' + value; ```
…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
This is a follow-up on facebook#9584 (comment). There is no need to assign the value property of an input if the value property of the React component changes types, but stringifies to the same value. For example: ```javascript DOM.render(<input value="true" />, el) DOM.render(<input value={true} />, el) ``` In this case, the assignment to `input.value` will always be cast to the string "true". There is no need to perform this assignment. Particularly when we already cast the value to a string later: ```javascript // Cast `value` to a string to ensure the value is set correctly. While // browsers typically do this as necessary, jsdom doesn't. node.value = '' + value; ```
In #7359 I added a loose check before assigning the
valueattribute on all controlled inputs. This was originally added to account for some edge cases in Chrome/Safari when working on number inputs (see the discussion). However, at some point I added a specific check for number inputs and never removed this check for other input types.So that created an issue: #9561
This commit removes that loose check, adds tests for the associated cases, and updates old tests to be in line with the new expectation. I also added a new DOM test fixture and updated the input DOM fixtures to use the new format we're using in other tests.
Test page:
http://nh-controlled-text-input-numbers.surge.sh/text-inputs
Related issues:
#9561