New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove loose check on non-number controlled inputs. Fix trailing dot issue. #9584

Merged
merged 3 commits into from May 3, 2017

Conversation

Projects
None yet
7 participants
@nhunzaker
Collaborator

nhunzaker commented May 2, 2017

In #7359 I added a loose check before assigning the value attribute 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

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)
@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon May 2, 2017

Member

Maybe unrelated, but why does editing "controlled email" in the middle throw me to the end of the input?

Member

gaearon commented May 2, 2017

Maybe unrelated, but why does editing "controlled email" in the middle throw me to the end of the input?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon May 2, 2017

Member

Same question for URLs and passwords. I'm on latest stable Chrome on OSX.

Member

gaearon commented May 2, 2017

Same question for URLs and passwords. I'm on latest stable Chrome on OSX.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary May 2, 2017

Member

It's because it's now alway setting node.value. I'm guessing that implies a new, unrelated value and cursor position is discarded (example), which isn't what we want.

@nhunzaker could we just change the loose equality check to a strict one?

Member

aweary commented May 2, 2017

It's because it's now alway setting node.value. I'm guessing that implies a new, unrelated value and cursor position is discarded (example), which isn't what we want.

@nhunzaker could we just change the loose equality check to a strict one?

@aweary aweary self-assigned this May 2, 2017

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon May 2, 2017

Member

Haha, first instance of fixtures saving us? 😄

Member

gaearon commented May 2, 2017

Haha, first instance of fixtures saving us? 😄

@gaearon

See the bug above.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary May 2, 2017

Member

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.

Member

aweary commented May 2, 2017

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.

nhunzaker added some commits May 2, 2017

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.
@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker May 3, 2017

Collaborator

@aweary Good thought. For the time being, I've just added an extra bit to the build script to copy over index.html to 200.html for surge.sh. Could something like that live in the readme?

Good call too! The strict equality check totally did it.

http://nh-controlled-text-input-numbers.surge.sh/text-inputs

Collaborator

nhunzaker commented May 3, 2017

@aweary Good thought. For the time being, I've just added an extra bit to the build script to copy over index.html to 200.html for surge.sh. Could something like that live in the readme?

Good call too! The strict equality check totally did it.

http://nh-controlled-text-input-numbers.surge.sh/text-inputs

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon May 3, 2017

Member

@aweary Mind doing a full review?

Member

gaearon commented May 3, 2017

@aweary Mind doing a full review?

@aweary

aweary approved these changes May 3, 2017

I ran through the fixtures for text and number inputs in Chrome, Firefox, Safari, IE11, and Edge. Everything seems to be working great!

We need to include a requestAnimationFrame polyfill to test in older browsers, but I think we can do that in a follow-up.

out of date

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon May 3, 2017

Member

Do you want to take this into 15.6?

Member

gaearon commented May 3, 2017

Do you want to take this into 15.6?

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary May 3, 2017

Member

@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?

Member

aweary commented May 3, 2017

@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?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon May 3, 2017

Member

@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).

Member

gaearon commented May 3, 2017

@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).

@flarnie flarnie referenced this pull request May 3, 2017

Closed

React 15.6 Umbrella #9398

41 of 49 tasks complete
@flarnie

This comment has been minimized.

Show comment
Hide comment
@flarnie

flarnie May 3, 2017

Contributor

I agree - this would be good to get into the 15.6 release. I'll cherry-pick it.
Is there a reason we haven't merged this to master yet?

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?

Contributor

flarnie commented May 3, 2017

I agree - this would be good to get into the 15.6 release. I'll cherry-pick it.
Is there a reason we haven't merged this to master yet?

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?

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary May 3, 2017

Member

Is there a reason we haven't merged this to master yet?

I didn't want to merge until I was clear on how including this in 15.6 was handled.

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?

Nothing specific to these changes, Fiber requires requestAnimationFrame, so none of the fixtures are currently working in browsers that do not support it.

Member

aweary commented May 3, 2017

Is there a reason we haven't merged this to master yet?

I didn't want to merge until I was clear on how including this in 15.6 was handled.

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?

Nothing specific to these changes, Fiber requires requestAnimationFrame, so none of the fixtures are currently working in browsers that do not support it.

@aweary aweary merged commit 6875fa8 into facebook:master May 3, 2017

1 check passed

ci/circleci Your tests passed on CircleCI!
Details
renderControlled = (type) => {
let id = `controlled_${type}`;
<TestCase.ExpectedResult>
The text field's value should not update.

This comment has been minimized.

@brigand

brigand May 3, 2017

Contributor

Might change to {`The text field's value should not update.`} to make syntax highlighters happy.

@brigand

brigand May 3, 2017

Contributor

Might change to {`The text field's value should not update.`} to make syntax highlighters happy.

flarnie added a commit that referenced this pull request May 3, 2017

Remove loose check on non-number controlled inputs. Fix trailing dot …
…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

flarnie added a commit to flarnie/react that referenced this pull request May 3, 2017

Add 'dom' fixture to 15.6-dev branch
**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

flarnie added a commit to flarnie/react that referenced this pull request May 3, 2017

Add PR facebook#9584 to 15.6 change log
Updating the change log~ :)

**issue:**
facebook#9398

flarnie added a commit that referenced this pull request May 9, 2017

Add PR #9584 to 15.6 change log (#9598)
Updating the change log~ :)

**issue:**
#9398

flarnie added a commit to flarnie/react that referenced this pull request May 9, 2017

Add 'dom' fixture to 15.6-dev branch
**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
@@ -209,8 +209,7 @@ var ReactDOMInput = {
// browsers typically do this as necessary, jsdom doesn't.
node.value = '' + value;
}
// eslint-disable-next-line
} else if (value != node.value) {
} else if (node.value !== value) {

This comment has been minimized.

@Hypnosphi

Hypnosphi May 10, 2017

Contributor

shouldn't this be node.value !== '' + value to prevent unnecessary updates when you provide the same non-string value as before?

render(<input value={0}/>, el);

render(<input value={0}/>, el); // shouldn't reset value
@Hypnosphi

Hypnosphi May 10, 2017

Contributor

shouldn't this be node.value !== '' + value to prevent unnecessary updates when you provide the same non-string value as before?

render(<input value={0}/>, el);

render(<input value={0}/>, el); // shouldn't reset value

This comment has been minimized.

@nhunzaker

nhunzaker May 16, 2017

Collaborator

Good question. I'll write up test case.

@nhunzaker

nhunzaker May 16, 2017

Collaborator

Good question. I'll write up test case.

This comment has been minimized.

@nhunzaker

nhunzaker May 29, 2017

Collaborator

Good catch. Yes. I'll send out a PR shortly.

@nhunzaker

nhunzaker May 29, 2017

Collaborator

Good catch. Yes. I'll send out a PR shortly.

This comment has been minimized.

@nhunzaker

nhunzaker May 29, 2017

Collaborator

Done! #9806

@nhunzaker

nhunzaker May 29, 2017

Collaborator

Done! #9806

nhunzaker added a commit to nhunzaker/react that referenced this pull request May 29, 2017

Inputs should not mutate value on type conversion
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;
```

aweary added a commit that referenced this pull request May 30, 2017

Inputs should not mutate value on type conversion (#9806)
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;
```

flarnie added a commit that referenced this pull request May 31, 2017

Inputs should not mutate value on type conversion (#9806)
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;
```

flarnie added a commit to flarnie/react that referenced this pull request Jun 7, 2017

Remove loose check on non-number controlled inputs. Fix trailing dot …
…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

flarnie added a commit to flarnie/react that referenced this pull request Jun 7, 2017

Inputs should not mutate value on type conversion (facebook#9806)
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;
```

@renovate renovate bot referenced this pull request Feb 2, 2018

Open

Update dependency react to v16 #29

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment