-
Notifications
You must be signed in to change notification settings - Fork 46.4k
-
Notifications
You must be signed in to change notification settings - Fork 46.4k
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
Incorrect data in compositionend event when typing Korean on IE11 #10217
Comments
Does this reproduce with |
@robbertbrak you can use this JSFiddle which loads Also, that W3 key event test site is great, thanks for sharing that! |
@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? |
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 Similarly, there used to be a bug that IE11 moved the cursor position to the right, just before the 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. 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:
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. |
@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 // 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 :) |
…ebook#10217) * Add isUsingKoreanIME function to check if a composition event was triggered by Korean IME * Add Korean IME check alongside useFallbackCompositionData and disable fallback mode with Korean IME
…acebook#10217) * Add isUsingKoreanIME function to check if a composition event was triggered by Korean IME * Add Korean IME check alongside useFallbackCompositionData and disable fallback mode with Korean IME
Merged #12563 into master which should fix this. Will be out in the next release. |
To reproduce:
여름.
(on a QWERTY keyboard this is typed asdufma.
).Result: in the developer console a list of composition events and the contents of the data attribute is logged. However, the data of the first
compositionend
event is wrong. It should be 여, not 여르. See screenshot below.You can see that this is wrong by trying out the same thing on https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html. As seen in the screenshot below, a plain (non-React) input field emits a
compositionend
event with the proper data.This occurs with the latest version of React, but I have also seen this behaviour in older versions. An example of where this causes problems is in Draft JS.
The text was updated successfully, but these errors were encountered: