Change event fires too many times when inputing Chinese characters. #3926

chenxsan opened this Issue May 21, 2015 · 20 comments


None yet

When I was trying this example from, any Chinese characters inputted by Chinese pinyin input method would fire too many renders like:

screen shot 2015-05-21 at 14 04 36

Actually I would expect those not to fire before I confirm the Chinese character.

Then I tried another kind of input method - wubi input method, I got this:

screen shot 2015-05-21 at 14 17 15

It's weird too. So I did a test in jQuery:

screen shot 2015-05-21 at 14 05 12

Only after I press the space bar to confirm the character, the keyup event would fire.

I know it might be different between the implementation of jQuery keyup and react onChange , but I would expect the way how jQuery keyup handles Chinese characters instead of react's onChange.

@chenxsan chenxsan changed the title from Change event fires too much when inputing Chinese characters. to Change event fires too many times when inputing Chinese characters. May 21, 2015
spicyj commented May 21, 2015

cc @salier :) – What should we do here?


I think we should not fire onChange until the IME string is committed.

One way to handle this in ChangeEventPlugin would be to ignore all input events between compositionstart and compositionend, then use the input event immediately following compositionend.

I did some quick testing on OSX Chrome and Firefox with Simplified Pinyin and 2-Set Korean, and the event order and data seem correct enough. (I predict that we'll have problems with IE Korean, but we may get lucky.)

I think we may continue to see issues with alternative input methods like the Google Input Tools extension, but there may be workarounds for that.

Bertg commented Sep 15, 2015

This also influences how dialectic characters are typed for latin languages. For example on OS X inserting an é will fail using an international keyboard. Even the long press e and then use variant are failing here.

Sorry this seems to not be related. My apologies.


Is there any update? Suffering from this issue too.

spicyj commented Sep 23, 2015

None currently – this is not a high priority for us right now. I'd be happy to look at a pull request if anyone dives into fixing this.

pswai commented Oct 2, 2015

@salier It seems like IE does not fire input event after compositionend. I have tested on IE11 and Edge on Windows 10. It fires properly in Chrome and Firefox.

@lingceng lingceng added a commit to lingceng/ajax-chosen that referenced this issue Apr 28, 2016
@lingceng lingceng Fix problem when input with Chinese input method
Similar problem with:
Change event fires too many times when inputing Chinese characters
@lingceng lingceng referenced this issue in michaelperrin/ajax-chosen Apr 28, 2016

Fix problem when input with Chinese input method #2

@lingceng lingceng added a commit to lingceng/ajax-chosen that referenced this issue Apr 29, 2016
@lingceng lingceng Fix problem when input with Chinese input method
Similar problem with:
Change event fires too many times when inputing Chinese characters

in ie 9, Change event fires too many times when inputing Chinese characters again

zhaoyao91 commented Aug 5, 2016 edited

Hello, Facebook guys, in fact this issue causes a SERIOUS problem: we can't update input asynchronously with Chinese input.
For example, we can't use meteor reactive datasources or stores like redux, because they all feedback update asynchronously.
Here is a simplest example to show this problem, it use setTimeout to do async update:

I really hope you can fix this quickly, so that we won't waste efforts to workaround it here and there and over and over again.


Here is my workaround. If anyone face the same problem, you can have a look

eyesofkids commented Aug 16, 2016 edited

I made a simple example to demo how to use compositionstart and compositionend events to prevent inputing Chinese IME on onchange event problem.
Here is the link:

zhaoyao91 commented Aug 17, 2016 edited

@eyesofkids nice work, this could be made as the default implementation of onChange for input, textarea ...

@eyesofkids eyesofkids referenced this issue in effektif/react-mentions Aug 17, 2016

不能连续输入中文 (Input via IME broken) #68


nice work !

julen commented Aug 21, 2016

I was hitting the same issue and @eyesofkids' workaround works perfectly (thank you!).

After having the workaround in place, I was diving into React's source code to at least try to add a failing test for this —hoping to later add the expected behavior to the library— although it seems a bit complicated for someone unfamiliar with the internals.

Initially I was expecting that a test similar to what's already available for ChangeEventPlugin should work, i.e. simulating a native compositionStart/compositionUpdate and checking no onChange callback was fired; also checking onChange would only be fired once compositionEnd was simulated. However this doesn't seem to work.

Hence I was thinking that maybe checking for ChangeEventPlugin.extractEvents() would be a feasible approach, similar to what's done in the tests for SelectEventPlugin. Here for some reason I always get undefined when extracting the events though.
For reference, this is the test code I tried within ChangeEventPlugin-test.js:

  var EventConstants = require('EventConstants');
  var ReactDOMComponentTree = require('ReactDOMComponentTree');
  var topLevelTypes = EventConstants.topLevelTypes;

  function extract(node, topLevelEvent) {
    return ChangeEventPlugin.extractEvents(
      {target: node},

  function cb(e) {
  var input = ReactTestUtils.renderIntoDocument(
    <input onChange={cb} value='foo' />


  var change = extract(input, topLevelTypes.topChange);

I'm afraid I don't know exactly how one is supposed to debug these tests—otherwise I'd have a clearer picture of what's going on. Any guidance on how to proceed or any other pointers would be highly appreciated.

julen commented Sep 13, 2016

The workaround suddenly broke in Chrome 53+ and it seems it is not valid anymore because they changed the order compositionend is fired: previously it happened before textInput, now after textInput. As a consequence of this, change won't be fired if it is aborted while in composition 😕.

eyesofkids commented Oct 5, 2016 edited

There is a tricky solution for Chrome v53. To call the handlechange after compositionend is fired.

handleComposition  = (event) => {

    if(event.type === 'compositionend'){
      onComposition = false

      //fire change method to update for Chrome v53

    } else{
      onComposition = true

check the demo here:


@chenxsan did you find out the solution?
you can detect the compositionStart and let a variable equal to true.
Then to use the variable, which you set, at onChange to see if it should fire the query

@jquense jquense added a commit to jquense/react that referenced this issue Dec 14, 2016
@jquense jquense Allow simulated native events to propagate
fixes #7211 fixes #6822 fixes #6614

we should make sure it doesn't break #3926 any worse (or works with #8438)
eyesofkids commented Jan 4, 2017 edited

I have submited a new issue for controlled components in #8683

The temporary solution for uncontrolled and controlled components(input, textarea) is uploaded to react-compositionevent.

yesmeck commented Jan 5, 2017 edited

Let's make #8438 happen.

eyesofkids commented Jan 6, 2017 edited

@yesmeck very happy to see this news.

I saw the test only focus on the Webkit, it should be separate into Chrome and Safari because Chrome change its compositionend event triggered order after 53+.

yesmeck commented Jan 8, 2017

@eyesofkids Added a new test case for Chrome under 53.

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