Does this reproduce with react@next and react-dom@next? The UMD locations have changed there, it would be /umd/react.development.js and /umd/react-dom.development.js.

@robbertbrak you can use this JSFiddle which loads react@next and react-dom@next as a starting point. I can try to reproduce this later as well.

Also, that W3 key event test site is great, thanks for sharing that!

cc @flarnie @spicyj who also might have context on this

@gaearon Yes, this is still reproducible in react@next. With this JSFiddle I get the same issue: https://jsfiddle.net/robbertbrak/68rwz1mr/2/ (sorry for the horrible code in that Fiddle, but it seems that JSFiddle with Babel+JSX and IE11 don't work well together...)

@aweary Glad to help out. Actually I got that W3 site from @hellendag, who referred to it in facebookarchive/draft-js#311 :)

It's a great resource! We have a handful of open issues related to composition events. It's something we need to look into more, and a good candidate for our DOM fixtures, so thanks for bringing this to our attention!

Additional thanks - this will be helpful to the Draft.js project too. We also have open issues there related to composition, and the Korean IME in particular, and it could be that they were hard to track down because the issue is actually in React.

It would be great if there was some way to simulate those in DOM fixtures so that we don’t have to type with special layouts.

There isn't a good way to simulate this without sidestepping the exact thing we want to test in the first place.

cc @msmania who might be interested here.

Could we use the Language and Keyboard settings on OSX to simulate this? What input settings should we use?

http://osxdaily.com/2013/06/21/mac-virtual-keyboard-os-x/

Each browser provides rather different events depending on the browser/OS/keyboard combo. The only way to test this properly is to get a real copy of IE11 and set your keyboard input to the proper language. (For example, in the past I have broken Korean input on Chrome Windows while trying to fix Korean input on Chrome Mac. You would think they're the same but they are not.)

Yes, and it gets worse. Apparently not even all versions of IE11 behave the same. For example, I once made this screenshot of IE11:

You can see that IE11 emitted the wrong Korean character in the compositionend event. Luckily, it seems that Microsoft fixed this in later versions of IE11.

Similarly, there used to be a bug that IE11 moved the cursor position to the right, just before the compositionstart event when typing Korean. This has recently been fixed as well.

All this means that it is very hard for Draft.js to do the right thing, because it relies on the correct Javascript events being fired. Workarounds that are appropriate for one browser/OS/IME may not work for other combinations, or suddenly stop working.

Thanks @spicyj for looping me in this discussion. I think this is one of the know issues. Let me see what we can do..

I also confirmed the data property in the composition end was wrong in IE11/Win8.1 and IE11/Win7.
This issue has been fixed in all Win10 family as mentioned in the above comment. This is IE11's bug, but does this particular issue break the behavior of React or Draft.js?

The actual issue I know is that when we type 'dufma.' on the Draft editor, the text "여르름." is committed, while the expected text is "여름.". This issue still happens in IE11/Win10. The root cause of this issue is that the fallback logic in React does not go well with Korean IME.

What the fallback logic does is:

1. Pick up the element's text at compositionstart and cache it as FallbackCompositionState._startText
2. Pick up the element's text at compositionend and do diff'ing it with the cached value
3. Build the beforeinput event with a diff'ed character

In the scenario of typing 'dufma.' with Korean IME, the text at compositionstart is 'ㅇ', the text at compositionend is '여르', and thus the diff'ed result is '여르'. As a result, the beforeinput event is fired with the text '여르' though the second character '르' is not committed.

In IE11, React does not use the data property in composition events probably because React does not trust it.

In IE11, React does not use the data property in composition events probably because React does not trust it.

@msmania Is it known why React does not trust it? E.g., for which IME's is the data property incorrect in IE11?

@robbertbrak Yes, it's mentioned in BeforeInputEventPlugin.js. It seems that Japanese character \u3000 is one case, but I'm not sure about any other cases.

https://github.com/facebook/react/blob/master/src/renderers/dom/shared/eventPlugins/BeforeInputEventPlugin.js#L42-L48

// In IE9+, we have access to composition events, but the data supplied
// by the native compositionend event may be incorrect. Japanese ideographic
// spaces, for instance (\u3000) are not recorded correctly.
var useFallbackCompositionData =
  ExecutionEnvironment.canUseDOM &&
  (!canUseCompositionEvent ||
    (documentMode && documentMode > 8 && documentMode <= 11));

I've been recently investigating IME problems in the Slate editor — which uses React to manage the contenteditable and listen for events. Just wanted to share that I've created a riff on the Keyboard Events Viewer that shows native UI events and the ones emitted by React: https://danburzo.github.io/input-methods/ — I found it helps me a lot in debugging IMEs. (I haven't tested it on IE yet, unfortunately, so YMMV)

I also plan to include a comprehensive writeup of IME scenarios (taking a cue from this excellent page by the VSCode team), to have an input methods test suite of sorts.

(Sorry for inviting myself into this issue :P)

@danburzo Those pointers are fantastic! The UI events viewer seems to work pretty well in IE. So thanks for inviting yourself in :)

Merged #12563 into master which should fix this. Will be out in the next release.