Skip to content
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

Change event fires extra times before IME composition ends #3926

chenxsan opened this issue May 21, 2015 · 48 comments

Change event fires extra times before IME composition ends #3926

chenxsan opened this issue May 21, 2015 · 48 comments


Copy link

@chenxsan chenxsan commented May 21, 2015

Extra details

  • Similar discussion with extra details and reproducing analysis: #8683
  • Previous attempt to fix it: #8438 (includes some unit tests, but sufficient to be confident in the fix)

Original Issue

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 Change event fires too much when inputing Chinese characters. Change event fires too many times when inputing Chinese characters. May 21, 2015
Copy link

@sophiebits sophiebits commented May 21, 2015

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

Copy link

@hellendag hellendag commented May 21, 2015

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.

Copy link

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

Copy link

@jasonslyvia jasonslyvia commented Sep 16, 2015

Is there any update? Suffering from this issue too.

Copy link

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

Copy link

@pswai 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 added a commit to lingceng/ajax-chosen that referenced this issue Apr 28, 2016
Similar problem with:
Change event fires too many times when inputing Chinese characters
lingceng added a commit to lingceng/ajax-chosen that referenced this issue Apr 29, 2016
Similar problem with:
Change event fires too many times when inputing Chinese characters
Copy link

@suhaotian suhaotian commented May 31, 2016

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

Copy link

@zhaoyao91 zhaoyao91 commented Aug 5, 2016

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

Copy link

@eyesofkids eyesofkids commented Aug 16, 2016

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:

Copy link

@zhaoyao91 zhaoyao91 commented Aug 17, 2016

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

Copy link

@suhaotian suhaotian commented Aug 18, 2016

nice work !

Copy link

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

Copy link

@julen 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 😕.

Copy link

@suhaotian suhaotian commented Sep 13, 2016

Copy link

@eyesofkids eyesofkids commented Oct 5, 2016

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:

Copy link

@vincent714 vincent714 commented Oct 9, 2016

@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

Copy link

@crochefluid crochefluid commented Aug 29, 2018

@gaearon I'm gonna try it. Did you try that test on safari (mac/IOS)?

Copy link

@gaearon gaearon commented Aug 29, 2018

It’s a Node test but it encodes sequences captured from different browsers and devices. Please see its source. You’d need to add sequences that are failing.

Copy link

@yesmeck yesmeck commented Oct 16, 2018

So I suppose this issue is only about the extra onChange calls.


Copy link

@robbyemmert robbyemmert commented Oct 16, 2018

I'm still getting this issue. It looks like this issue has been open for 3 years, does React support Chinese input in controlled components at the moment?

Copy link

@cbengtson85 cbengtson85 commented Oct 26, 2018

Also seeing this in Japanese with certain characters...

Copy link

@robbyemmert robbyemmert commented Oct 27, 2018

Here's a code sandbox that reproduces my issue. Looks like it's related to forms. Using inputs directly is fine.

Copy link

@robbyemmert robbyemmert commented Oct 27, 2018

I added some cases:
Using react state and plain inputs is fine
Using react state, plain forms, and plain inputs is fine
We're using a context-based form component which isn't working. It might be a context-related issue.

Copy link

@robbyemmert robbyemmert commented Oct 27, 2018

Problem solved: I got it working in codepen. For some reason passing 'input' in as a component worked, when passing (props) => <input {...props]/> did not.

Anyone have an idea what the difference is?

Actually, I've also tried:


<Field {...otherProps} component="input" />

Doesn't work

<Field {...otherProps} component={(props) => <input {...props} />} />

Works oddly enough

const WrappedInput = (props) => <input {...props} />
<Field {...otherProps} component={WrappedInput} />

Clearly there is some magic going on here that I don't understand. 😕

Copy link

@makotot makotot commented Jan 10, 2019

Any updates?

Copy link

@otakustay otakustay commented Feb 21, 2019

It seems to cause incorrect result when IME is enabled


Copy link

@knubie knubie commented Feb 26, 2019

I've experienced the same issue as @otakustay
It seems impossible to support controlled input with IME input. I've traced the sequence of events to the following.

  1. User types a letter, say w
  2. onChange is triggered
  3. State is updated with new value
  4. New value is propagated down to the input by way of the value attribute.
  5. The IME "composition" is interrupted at this point
    • There is a w string in the input element
    • There is also a separate w string stored in the IME buffer
  6. The user types another letter, say a
  7. The string in the input a combines with the string the IME buffer to produce wwa.
  8. Repeat steps 1-7 to get a bunch of duplicate characters.

I've noticed that the bug only occurs if the input re-renders >15ms after the compositionUpdate event after the next repaint.

Right now my only solution is to switch away from controlled inputs.

Edit: Here is a simple reproduction:
Edit2: Here is my hacky workaround: cc: @otakustay

Copy link

@blessonbabu blessonbabu commented Aug 21, 2019

Any updates on this?

Copy link

@huawin03 huawin03 commented Oct 24, 2019

update ??

Copy link

@turutosiya turutosiya commented May 11, 2020

Any update on this?

Copy link

@eugle eugle commented Jun 19, 2020

Stunned, I was confronted with this question

Copy link

@cpdyj cpdyj commented Sep 12, 2020

Interesting, looks the problem is not only about the multi-times onChange. If we not setState between the onCompositionStart and onCompositionEnd, the react will "control" the value as is. This action will interrupt the composition. That means we will not get the onCompositionEnd event......(If I'm wrong mention me plz.) But we can only change the state immediately(Otherwise we'll have to face the problem @knubie mentions). A reproduction at here(Looks like a "half-controlled" component):

But I'm so surprised the problem has no fix during five years 😢

Copy link

@craigkovatch craigkovatch commented Sep 12, 2020

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

I don't think this is a valid solution as a component might want to know the "uncommitted" IME string for e.g. filtering options in a list as the user types.

I am not sure if the approach I use in this other thread might help those hitting this issue, but here's a link just in case: #13104 (comment)

Copy link

@kazukinagata kazukinagata commented Sep 28, 2020

any updates?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.