Fix Chrome number input backspace and invalid input issue #7359

nhunzaker · 2016-07-27T01:15:46Z

In Google Chrome, backspacing an controlled and uncontrolled number inputs causes an unexpected behavior:

More cases (and what fixes look like) here: #7253 (comment)

Issues with uncontrolled inputs

This is because assigning defaultValue causes side-effects on value. It seems to trigger validation on value as if it were directly assigned itself.

This Codepen provides a step by step reproduction case:

http://codepen.io/nhunzaker/pen/zBaokp

This PR wraps the defaultValue assignment in a conditional so that it will only ever be assigned if the defaultValue has changed.

Issues with controlled inputs

It looks like the issue here is that value is being assigned using the standard React method of updating attributes when the props get passed in here:

https://github.com/facebook/react/blob/master/src/renderers/dom/shared/ReactDOMComponent.js#L926

There is some logic in ReactDOMInput to prevent duplicate values from being assigned here:

https://github.com/facebook/react/blob/master/src/renderers/dom/client/wrappers/ReactDOMInput.js#L201-L210

Unfortunately the new value has already been assigned.

This PR adds a check for the value prop, and only assigns it if is different. It never assigns the value attribute if it hasn't changed:

I don't really know why this works. I didn't think node.setAttribute('value', value) was meaningful. What do you think?

Related to #7253

zpao · 2016-07-28T23:37:50Z

src/renderers/dom/shared/DOMPropertyOperations.js

+        } else if (attributeName === 'value') {
+          if (node.value != value) {
+            node.value = '' + value;
+          }


Ironically our code used to look a lot like this… https://github.com/facebook/react/blob/0.14-stable/src/renderers/dom/shared/DOMPropertyOperations.js#L187-L197

@jimfb - I think this is more fallout from your changes. Can you take a look and figure out a way forward?

Ack! I crossed the streams!

This PR was supposed to be solely for fixing defaultValue, but it looks I got my branches mixed up and pushed the more general fix for both inputs. I actually just replied here:

#7253 (comment)

Again, pushing to this branch was a total accident. A bunch of tests fail now. I'll work on getting those to pass in the mean time, but could definitely use some advice.

nhunzaker · 2016-07-29T01:09:28Z

@zpao Thanks for the historical insight. All tests pass. I believe I've caught every edge case. I'll enumerate them in #7253. I'm happy to add back the HAS_SIDE_EFFECTS constant, however this seems to be truly specific to the value attribute. What do you think?

nhunzaker · 2016-07-29T01:48:44Z

Cases enumerated here:

#7253 (comment)

nhunzaker · 2016-07-29T01:50:46Z

Ah and it looks like lint is going to fail because my solution relies on loose type coercion. Hmm. Do I have permission to ignore these rules?

nhunzaker · 2016-07-29T01:58:03Z

src/renderers/dom/shared/DOMPropertyOperations.js

@@ -158,6 +158,10 @@ var DOMPropertyOperations = {
        } else if (propertyInfo.hasBooleanValue ||
                   (propertyInfo.hasOverloadedBooleanValue && value === true)) {
          node.setAttribute(attributeName, '');
+        } else if (attributeName === 'value' && node.hasAttribute('value')) {


Type coercion solved my problems, however it makes the initial case hard. Empty inputs are always equal to 0.

I think this could be better. Any suggestions?

nhunzaker · 2016-08-01T12:21:37Z

Added ignore statements for ESLint rules and a test for setAttributeForProperty.

nhunzaker · 2016-08-01T12:25:34Z

src/renderers/dom/shared/DOMPropertyOperations.js

+          // Use loose coercion to prevent replacement on comparisons like
+          // '3e1' == 30 in Chrome (~52).
+          if (node.value != value) { // eslint-disable-line
+            node.setAttribute(attributeName, '' + value);


One thing I'm not clear on yet: Why assign the value attribute at all?.

ReactDOMInput will assign the value property in updateWrapper. We could do that in mountWrapper as well. Is it important that the attribute be assigned?

So, there's a difference between setting node.value and calling node.setAttribute('value'). node.value tracks the value of the node in JS, and setAttribute will actually set the attribute on the element in the DOM.

This change causes an issue where the DOM attribute is never updated, because node.value is already updated prior to this check, so it never actually sets the attribute.

Hmm. So actually: should the value attribute update for anything other than checkbox and radio?

Following browser behavior, editing the text inside of a text input doesn't update the value attribute.

Possible my current code doesn't do this, but to me that's the correct functionality.

React does deviate from browser behavior when it comes to controlled components (e.g., change events on keydown instead of on blur). Currently the value attribute does update on controlled inputs, and it looks like we're explicitly setting it, so there may be a good reason I'm not aware of.

cc @spicyj @zpao

There is an extra complication here... Assigning the value attribute forces validation for number inputs. Check this out:

Notice how the decimal gets stripped? My fix focuses on avoiding touching the input as much as possible to avoid unexpected behavior like this. Fortunately, I believe this also conforms to the standard way inputs work.

I believe the current behavior of setting the attribute is intentional though I could be misremembering. I know we definitely need to set value on the <progress> element. You can look at the history of ReactDOMInput to see when jimfb last made changes.

Looks like this is taken care of, because node.value on progress is never assigned, so it's out of sync with props.value, and it reassigns the attribute.

STRML · 2016-08-24T15:23:14Z

Anything this is waiting on? This is a pretty obnoxious bug. Thanks so much to @nhunzaker for putting this PR together.

aweary · 2016-08-24T23:25:21Z

I'll try and get this reviewed when I get back from vacation next week, if no one else gets a chance to do it in the meantime. Overall it looks good to me though!

nhunzaker · 2016-08-25T02:31:16Z

@aweary No worries -- I'm on vacation too! Looking forward to getting this ~~one~~ fix in...

nhunzaker · 2017-03-25T14:18:21Z

Rebased with master. I also added @iangilman's case for trailing dashes, and a test case for negative numbers:

jquense · 2017-03-25T14:28:08Z

I'm interested in why 3- needs to be supported (if only to make sure react-widgets does it)

nhunzaker · 2017-03-25T14:34:30Z

@jquense You know what, I think I have this wrong. The test case is when you select the entire number value and - to start typing a new number. Stable react sees - as an invalid number and wipes away the value.

I'll update the test case. I also need to figure out what to do about prettier formatting. prettier wants to put my ESLint ignore comments on a new line, which causes linting to fail.

Away I go.

jquense · 2017-03-25T14:44:17Z

ah gotcha. If it helps btw please feel free to look at https://github.com/jquense/react-widgets/blob/v4/packages/react-widgets/src/NumberInput.js to see how i fumbled through on this logic

Also run prettier

nhunzaker · 2017-03-25T14:46:43Z

Cool. I just had to update the test case, everything works fine. If the number isn't valid, it parses to a blank value, which is also what the number input reports, so no change occurs.

I've also run prettier on this branch and dealt with the associated eslint issue.

nhunzaker · 2017-03-25T14:48:12Z

@jquense This NumberInput is cool. How crazy would it be to bake something like this into React?

Later... later.. I want to get this PR merged so badly, haha.

aweary

Later... later.. I want to get this PR merged so badly, haha.

Oh yeah? well, how about we go ahead and do that then 😄 I was able to test this out today using the DOM fixtures. I verified everything seems to be working correctly in:

IE9
IE10
IE11
Edge 14
Chrome 57 (Windows)
Chrome 57 (macOS)
Chrome (Android, Galaxy S5)
Firefox 52 (Windows)
Firefox 52 (macOS)
Opera 44 (Windows)
Safari 10 (macOS)
Safari (iOS 9)
Safari (iOS 8)

Everything appears to be working great, and I see nothing immediately wrong with the changes made. So, LGTM!

* Only re-assign defaultValue if it is different * Do not set value if it is the same * Properly cover defaultValue * Use coercion to be smart about value assignment * Add explanation of loose type checks in value assignment. * Add test coverage for setAttribute update. * Only apply loose value check to text inputs * Fix case where empty switches to zero * Handle zero case in controlled input * Correct mistake with default value assignment after rebase * Do not assign bad input to number input * Only trigger number input value attribute updates on blur * Remove reference to LinkedValueUtils * Record new fiber tests * Add tests for blurred number input behavior * Replace onBlur wrapper with rule in ChangeEventPlugin * Sift down to only number inputs * Re-record fiber tests * Add test case for updating attribute on uncontrolled inputs. Make related correction * Handle uncontrolled inputs, integrate fiber * Reorder boolean to mitigate DOM checks * Only assign value if it is different * Add number input browser test fixtures During the course of the number input fix, we uncovered many edge cases. This commit adds browser test fixtures for each of those instances. * Address edge case preventing number precision lower than 1 place 0.0 coerces to 0, however they are not the same value when doing string comparision. This prevented controlled number inputs from inputing the characters `0.00`. Also adds test cases. * Accommodate lack of IE9 number input support IE9 does not support number inputs. Number inputs in IE9 fallback to traditional text inputs. This means that accessing `input.value` will report the raw text, rather than parsing a numeric value. This commit makes the ReactDOMInput wrapper check to see if the `type` prop has been configured to `"number"`. In those cases, it will perform a comparison based upon `parseFloat` instead of the raw input value. * Remove footnotes about IE exponent issues With the recent IE9 fix, IE properly inserts `e` when it produces an invalid number. * Address exception in IE9/10 ChangeEventPlugin blur event On blur, inputs have their values assigned. This is so that number inputs do not conduct unexpected behavior in Chrome/Safari. Unfortunately, there are cases where the target instance might be undefined in IE9/10, raising an exception. * Migrate over ReactDOMInput.js number input fixes to Fiber Also re-record tests * Update number fixtures to use latest components * Add number input test case for dashes and negative numbers * Replace trailing dash test case with replace with dash Also run prettier

sebmarkbage · 2017-03-30T02:00:03Z

src/renderers/dom/shared/eventPlugins/ChangeEventPlugin.js

+  // If controlled, assign the value attribute to the current value on blur
+  let value = '' + node.value;
+  if (node.getAttribute('value') !== value) {
+    node.setAttribute('value', value);


Sorry, I'm not caught up on the entire history here.

Why is this special case needed? extractEvents should not have side-effects in it.

Can this be handled by the normal controlledness flow in updateWrapper?

Would it be enough to flag this with enqueueStateRestore so that the normal updateWrapper kicks in at the end of the blur event?

I can verify. As for history:

React controlled inputs sync up the value attribute with the value property. This prevents state mismatches with form.reset() and browser plugins (though i never got a reply on which ones). Unfortunately, on number inputs in Chrome and Safari, this forces a check on the input, removing trailing decimal places, invalid characters, etc.

The only way i could get around this (i tried for months, off and on) was to defer setting the value attribute on blur.

I haven't done much with enqueueStateRestore. I'll give it a go.

IMO we should just not set the value attribute. People writing manual DOM operations don't do that and it works fine for them, so not sure why we do.

Would just avoiding setting the attribute all together fix the problem?

That would be lovely. The only edge case is form.reset(). Honestly, I'd be in favor of just adding a warning about this, or enqueing updateWrapper on the reset form event if it can be done.

We also need to be clear that form.reset is totally fine when the form contains only uncontrolled inputs. If we did go the route of warning it should only warn if the form contains one or more controlled inputs.

I think just .reset() and CSS input[value=foo] selectors. TBH the latter was a pretty common feature request so I'd be sad to see it go.

There are other attributes that matter. Such as all of those that don't have corresponding properties (generally things outside the HTML spec). There are edge cases that need removing attributes (like progress). However, for value (or checked) I don't believe there were any cases that needed it outside of intuition. E.g. the attribute shows up in DOM dev tools in Chrome etc.

However, there is nothing that relies on it being there because all those thousands of websites that do manual DOM management. Nobody manually calls setAttribute in those cases. However, as we've seen, there are cases where setting it all the time is unusual such as in this case. So it leads to undiscovered browser deviations.

That's why I think our design should be to model what a user would write manually - even if that seems unintuitive of how people think React works.

In most cases I can think of with manual manipulation it's actually undesirable to set the value attribute because you want to rely on form.reset. at least, this has always been the case for me. Being able to style text inputs based on a dynamic value attribute is a privilege react provides, one I would be comfortable with no longer having.

React doing Dom manipulation, the correct way, is the abstraction I've always had. I think this is a very strong metaphor that makes it easier to reason about what react is doing. We deviate from that with controlled inputs. I'm in favor of this change, which moves closer towards that idea.

So I agree, armchair theory aside 😂. I can start scaffolding out what that would look like, but I won't be able to pick it up until Monday, if someone else wants to give it a shot.

Oof. I finally did it. Please see:

#10150

btoueg · 2017-04-12T13:27:47Z

I've bumped my project to 15.5.4 and the issue is still there.

gaearon · 2017-04-12T13:29:50Z

@btoueg Provide a reproducing case please?

btoueg · 2017-07-12T07:50:11Z

Sorry for the delay. My report was a false negative. Works fine now, congrats on fixing the issue.

nhunzaker mentioned this pull request Jul 27, 2016

Bug: Backspace in input type="number" behaves badly in Blink #7253

Closed

ghost added GH Review: review-needed CLA Signed labels Jul 27, 2016

zpao reviewed Jul 28, 2016
View reviewed changes

ghost added the CLA Signed label Jul 28, 2016

nhunzaker changed the title ~~Fix Chrome uncontrolled number input backspace issue. Only re-assign defaultValue if it is different~~ Fix Chrome number input backspace and invalid input issue Jul 29, 2016

ghost added the CLA Signed label Jul 29, 2016

nhunzaker reviewed Jul 29, 2016
View reviewed changes

nhunzaker force-pushed the nh-chrome-backspace branch 2 times, most recently from 1e2a9ab to dcd31d3 Compare August 1, 2016 12:20

nhunzaker reviewed Aug 1, 2016
View reviewed changes

ghost added the CLA Signed label Aug 1, 2016

nhunzaker force-pushed the nh-chrome-backspace branch from dcd31d3 to 1b097ff Compare August 2, 2016 23:42

ghost added the CLA Signed label Aug 2, 2016

nhunzaker mentioned this pull request Aug 3, 2016

Fix <input> with type date/time/etc. issue on mobile browsers #7397

Merged

zpao added Component: DOM and removed Component: DOM labels Aug 3, 2016

ghost added the CLA Signed label Aug 3, 2016

This was referenced Aug 4, 2016

Proposal for an ordered attribute white list, and new property injection types #7428

Closed

Use an ordered property list for inputs, fix some Chrome number input issues #7474

Closed

ghost added the CLA Signed label Aug 24, 2016

ghost added the CLA Signed label Aug 25, 2016

nhunzaker force-pushed the nh-chrome-backspace branch from 1b097ff to 149dfc3 Compare September 1, 2016 15:18

nhunzaker force-pushed the nh-chrome-backspace branch from 67ed49f to 4a3eeca Compare March 25, 2017 14:18

Replace trailing dash test case with replace with dash

7cb979f

Also run prettier

nhunzaker mentioned this pull request Mar 26, 2017

React shouldn't bind wheel or touch events to the document. #1254

Closed

aweary approved these changes Mar 27, 2017

View reviewed changes

aweary merged commit 29d9710 into facebook:master Mar 27, 2017

aweary added this to the 15-hipri milestone Mar 27, 2017

nhunzaker mentioned this pull request Mar 27, 2017

Losing control of <input type='number' /> #1549

Closed

sebmarkbage reviewed Mar 30, 2017

View reviewed changes

nhunzaker mentioned this pull request Apr 6, 2017

TypeError: Cannot read property 'firstChild' of null at precacheChildNodes (react-dom.js:6619) #9351

Closed

jbalboni mentioned this pull request Apr 20, 2017

ErrorableNumberInput removing decimal unexpectedly department-of-veterans-affairs/vets-website#3542

Closed

nhunzaker mentioned this pull request May 2, 2017

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

Merged

nhunzaker mentioned this pull request Jul 11, 2017

Controlled inputs do not synchronize value or checked attribute #10150

Closed

hyperknot mentioned this pull request Aug 25, 2017

Buggy controlled number input on 15.5+ #10539

Closed

YellowKirby mentioned this pull request Dec 11, 2017

Cursor jumps when backspacing in a number input (with ShadowDOM) #11827

Closed

aweary mentioned this pull request Dec 20, 2017

Stop syncing value attribute for controlled inputs #11896

Open

renovate bot mentioned this pull request Feb 2, 2018

Update dependency react to v0.14.9 - autoclosed signavio/backbone-rel#29

Closed

1 task

nhunzaker mentioned this pull request Jun 9, 2018

html value attribute of input type "number" element is only updated on blur #13007

Closed

gaearon mentioned this pull request Aug 30, 2018

Add <progress> to DOM fixtures #13518

Closed

jameslahm mentioned this pull request Aug 15, 2020

fix: synchronize focused email input on blur to avoid check validity when inputting #19621

Closed

tqwewe mentioned this pull request Oct 28, 2023

<intput> with f64 values and interactive editing leptos-rs/leptos#1956

Closed

Fix Chrome number input backspace and invalid input issue #7359

Fix Chrome number input backspace and invalid input issue #7359

Conversation

nhunzaker commented Jul 27, 2016 • edited Loading

Issues with uncontrolled inputs

Issues with controlled inputs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhunzaker commented Jul 29, 2016

nhunzaker commented Jul 29, 2016

nhunzaker commented Jul 29, 2016 • edited Loading

Choose a reason for hiding this comment

nhunzaker commented Aug 1, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhunzaker Sep 4, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

STRML commented Aug 24, 2016

aweary commented Aug 24, 2016

nhunzaker commented Aug 25, 2016 • edited Loading

nhunzaker commented Mar 25, 2017

jquense commented Mar 25, 2017

nhunzaker commented Mar 25, 2017

jquense commented Mar 25, 2017

nhunzaker commented Mar 25, 2017

nhunzaker commented Mar 25, 2017

aweary left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhunzaker Mar 30, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhunzaker Mar 31, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

btoueg commented Apr 12, 2017

gaearon commented Apr 12, 2017

btoueg commented Jul 12, 2017

nhunzaker commented Jul 27, 2016 •

edited

Loading

nhunzaker commented Jul 29, 2016 •

edited

Loading

nhunzaker Sep 4, 2016 •

edited

Loading

nhunzaker commented Aug 25, 2016 •

edited

Loading

nhunzaker Mar 30, 2017 •

edited

Loading

nhunzaker Mar 31, 2017 •

edited

Loading