Bug: <input type="number"> resets value if @value or @defaultValue is provided

[ixrock]

Demo:
http://codepen.io/anon/pen/LxpyLB

Problem:
<input type=number> resets its value when I type "." instead of default behaviour (trigger input::invalid html5 state).

Source code if demo not available:

<!-- demo.html -->
<p><b>Bug:</b></p>
<div id="test"></div>

<p><b>Normal html5 behavior:</b></p>
<div>
  <input type="number" value="20" /><br/>
  <input type="number" />
</div>

/* demo.css */
input:invalid {
  outline: 1px solid red;
}

// demo.js
class Test extends React.Component {
  public state = {value: 11};
  
  render(){
    return (
      <div>
      <p>1: 
      <input type="number" defaultValue="10"/>
      <input type="number" value={this.state.value} onChange={e => this.setState({value: e.target.value})}/>
      fully resets value when type "."</p>
      <p>2: <input type="number"/> allows to type "." and hightlight invalid field</p>
      </div>
    )
  }
}
ReactDOM.render(<Test/>, document.querySelector('#test'))

[Andarist]

Dibs! Gonna play around with it and see what I can do to fix the issue.

[Andarist]

So my investigation shows that... it's already fixed with this commit. Although unfortunately it is not released yet.

[ixrock]

@Andarist it seems like that commit might fix a problem only with uncontrolled input, but the issue happens as well with controlled inputs, when @value and @onChange are used.
I've updated the demo and code in first post to show this.

[Andarist]

Yeah, you are right, but I think there is nothing to be fixed on react's side here, as controlled inputs depends on setting controlled values directly on the DOM nodes.

Check out this demo and inspect the console. You'll see a warning (in Chrome) that:

The specified value "20." is not a valid number. The value must match to the following regular expression: -?(\d+|\d+\.\d+|\.\d+)([eE][-+]?\d+)?

It seems that react has already experienced similar issue here and it was reported (and fixed) in the Chromium's bugtracker here. I propose to report this one as well so it can be fixed.

[gaearon]

cc @nhunzaker who worked on related things before.

[nhunzaker]

Thanks!

So my investigation shows that... it's already fixed with this commit. Although unfortunately it is not released yet.

Yes! @gaearon we could probably cherry pick this to 15.x pretty safely. What do you think?

@Andarist it seems like that commit might fix a problem only with uncontrolled input, but the issue happens as well with controlled inputs, when @value and @onchange are used.

@ixrock Yes! I've been maintaining a PR for controlled inputs: #7359.

I propose to report this one as well so it can be fixed.

@Andarist I think this filing an issue with Chrome is a fantastic next step. I've also encountered this behavior in Safari 10.x. We should report it to them too. Happy to help clarify anything to help issue submission.

[gaearon]

Yes! @gaearon we could probably cherry pick this to 15.x pretty safely. What do you think?

This commit was in 15.4.2, no?

[gaearon]

Argh, I forgot to mention it in the changelog. Sorry.

[gaearon]

Updated the changelog. 6b1c860

[nhunzaker]

Anything else to do here?

[aweary]

Should be good to close, the behavior appears to be fixed in 15.4.2