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

EN-Dash Causes onChange to fire in IE11 on Render #2185

Closed
browniefed opened this Issue Sep 12, 2014 · 6 comments

Comments

Projects
None yet
4 participants
@browniefed

browniefed commented Sep 12, 2014

I don't know if this is an issue with React or IE11 but when an the input initially contains an EN-dash (8211) it fires the change event.
JSFiddle http://jsfiddle.net/uH539/10/

@browniefed browniefed changed the title from EN-Dash Causes onChange to fire in IE11 to EN-Dash Causes onChange to fire in IE11 on Render Sep 12, 2014

@syranide

This comment has been minimized.

Show comment
Hide comment
@syranide

syranide Sep 14, 2014

Contributor

I can't reproduce it outside of React and I can't find any related code in ReactDOMInput, I'm assuming ChangeEventPlugin is the culprit.

Contributor

syranide commented Sep 14, 2014

I can't reproduce it outside of React and I can't find any related code in ReactDOMInput, I'm assuming ChangeEventPlugin is the culprit.

@browniefed

This comment has been minimized.

Show comment
Hide comment
@browniefed

browniefed Sep 14, 2014

@syranide yeah I tried looking through the code but in my limited experience with internals of React couldn't find anything that would be caused by such a specific thing as adding in an en-dash (although I haven't looked if other characters cause it as well). Plus it doesn't happen in any other browser thus the IE11 specific issue.

It seems as if the event type that is being triggered is not of the change variety but of a beforeInput event or something along those lines.

browniefed commented Sep 14, 2014

@syranide yeah I tried looking through the code but in my limited experience with internals of React couldn't find anything that would be caused by such a specific thing as adding in an en-dash (although I haven't looked if other characters cause it as well). Plus it doesn't happen in any other browser thus the IE11 specific issue.

It seems as if the event type that is being triggered is not of the change variety but of a beforeInput event or something along those lines.

@syranide

This comment has been minimized.

Show comment
Hide comment
@syranide

syranide Sep 26, 2014

Contributor

@browniefed Sorry for forgetting about this, you are indeed correct about oninput. It affects inputs with any char not in the range x01 - x7F and appears on both IE10 and IE11. The oninput is not dispatched during innerHTML. It can easily be feature-tested for if necessary (but a positive result will be received after the current tick).

However, I see no obviously best/neat solution.

  1. ReactDOMInput could test value for any char not in x01 - x7F during componentWill/DidMount and (in some way) set a flag for the node. When an input-event is received it is discarded if the flag is set, the flag is then cleared, could also use setImmediate from componentWill/DidMount for clearing the flag (or both). Requires feature-testing and is potentially fragile.
  2. ReactDOMInput could store the initial value (in some way) for the node. When the input-event is received it is discarded if the current value equals the initial value, the stored value is always cleared when the event is received, could also use setImmediate from componentWill/DidMount to clear the stored value (or both). Can use feature-testing. Seems robust and simple. Unless there can be noop input-events then this should be 100%.
  3. ReactDOMInput sets a flag during componentWill/DidMount which is cleared by setImmediate. Super simple and robust, but if a legitimate input-event is somehow dispatched in the tick immediately after creation then it will be lost. I can't imagine how/why that would happen though (or?). Can use feature-testing.
  4. Have I missed something obvious?

Related: https://connect.microsoft.com/IE/feedback/details/816137/ie-10-11-input-elements-with-unicode-entity-character-values-cause-oninput-events-to-be-fired-on-page-load

cc @zpao @yungsters

Contributor

syranide commented Sep 26, 2014

@browniefed Sorry for forgetting about this, you are indeed correct about oninput. It affects inputs with any char not in the range x01 - x7F and appears on both IE10 and IE11. The oninput is not dispatched during innerHTML. It can easily be feature-tested for if necessary (but a positive result will be received after the current tick).

However, I see no obviously best/neat solution.

  1. ReactDOMInput could test value for any char not in x01 - x7F during componentWill/DidMount and (in some way) set a flag for the node. When an input-event is received it is discarded if the flag is set, the flag is then cleared, could also use setImmediate from componentWill/DidMount for clearing the flag (or both). Requires feature-testing and is potentially fragile.
  2. ReactDOMInput could store the initial value (in some way) for the node. When the input-event is received it is discarded if the current value equals the initial value, the stored value is always cleared when the event is received, could also use setImmediate from componentWill/DidMount to clear the stored value (or both). Can use feature-testing. Seems robust and simple. Unless there can be noop input-events then this should be 100%.
  3. ReactDOMInput sets a flag during componentWill/DidMount which is cleared by setImmediate. Super simple and robust, but if a legitimate input-event is somehow dispatched in the tick immediately after creation then it will be lost. I can't imagine how/why that would happen though (or?). Can use feature-testing.
  4. Have I missed something obvious?

Related: https://connect.microsoft.com/IE/feedback/details/816137/ie-10-11-input-elements-with-unicode-entity-character-values-cause-oninput-events-to-be-fired-on-page-load

cc @zpao @yungsters

@browniefed

This comment has been minimized.

Show comment
Hide comment
@browniefed

browniefed Sep 27, 2014

@syranide No problem, I ended up just comparing the this.state.value to event value and returning if they were the same as a simple workaround so it's not exactly a crucial thing just somewhat annoying.

browniefed commented Sep 27, 2014

@syranide No problem, I ended up just comparing the this.state.value to event value and returning if they were the same as a simple workaround so it's not exactly a crucial thing just somewhat annoying.

@syranide syranide added the Type: Bug label Sep 29, 2014

@zpao

This comment has been minimized.

Show comment
Hide comment
@zpao
Member

zpao commented Sep 29, 2014

cc @salier

@trygveaa

This comment has been minimized.

Show comment
Hide comment
@trygveaa

trygveaa Oct 14, 2015

I also experience this issue. In addition to when the value contains non-ascii characters, it happens the first time a value is set when the input element has a placeholder that contains non-ascii characters.

This code reproduces it outside of React. When the page loads, the text "failed" will be shown beneath the input-field, which it should not.

With a non-ascii value:

<meta charset="utf-8">
<body>
  <input value="å" onInput="javascript: document.getElementById('text').textContent = event.target.value;">
  <p id="text"></p>
</body>

With a non-ascii placeholder:

<meta charset="utf-8">
<script>
  document.addEventListener("DOMContentLoaded", function () {
    document.getElementById("input").value = "failed";
  }); 
</script>
<body>
  <input id="input" placeholder="å" onInput="javascript: document.getElementById('text').textContent = event.target.value;">
  <p id="text"></p>
</body>

While it is not an issue with React, it would be nice if React could add some workaround for it, since you easily run into this bug when using React. (I'm not sure what that workaround would be though.)

trygveaa commented Oct 14, 2015

I also experience this issue. In addition to when the value contains non-ascii characters, it happens the first time a value is set when the input element has a placeholder that contains non-ascii characters.

This code reproduces it outside of React. When the page loads, the text "failed" will be shown beneath the input-field, which it should not.

With a non-ascii value:

<meta charset="utf-8">
<body>
  <input value="å" onInput="javascript: document.getElementById('text').textContent = event.target.value;">
  <p id="text"></p>
</body>

With a non-ascii placeholder:

<meta charset="utf-8">
<script>
  document.addEventListener("DOMContentLoaded", function () {
    document.getElementById("input").value = "failed";
  }); 
</script>
<body>
  <input id="input" placeholder="å" onInput="javascript: document.getElementById('text').textContent = event.target.value;">
  <p id="text"></p>
</body>

While it is not an issue with React, it would be nice if React could add some workaround for it, since you easily run into this bug when using React. (I'm not sure what that workaround would be though.)

@jimfb jimfb closed this in #5746 Apr 15, 2016

jimfb added a commit that referenced this issue Apr 15, 2016

Only fire input value change events when the value changes (#5746)
* Only fire input value change events when the value changes

fixes #554, fixes #1471, fixes #2185 (still trying to figure out why)

* catch programmatic value changes

* move value tracking to seperate module

ajreed79 pushed a commit to ajreed79/react that referenced this issue Aug 29, 2016

Only fire input value change events when the value changes (#5746)
* Only fire input value change events when the value changes

fixes #554, fixes #1471, fixes #2185 (still trying to figure out why)

* catch programmatic value changes

* move value tracking to seperate module
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment