Korean typing is so slow in Chrome browser

doortts commented 7 years ago

Do you want to request a feature or report a bug? bug

What is the current behavior? Korean typing is so slow and lagging in Chrome browser. (Firefox & Safari is OK)

Especially, if you hold pressing the backspace key to erase a character, it seems that it does not work properly. It looks like doing nothing.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started:

You can see: https://youtu.be/gnLmiaw7Sf0

The sequence is 'typing and pressing back space. English and Korean with same sequence. English is erased smoothly but Korean is very very slow.

It is tested at https://draftjs.org/

What is the expected behavior?

Works same as English.

Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?

It is tested at https://draftjs.org/ Probably latest version.

doortts commented 7 years ago

@flarnie Is there any clue or plan to fix this problem? I'm waiting and also many others (maybe) be the same..

nburt commented 7 years ago

We've had several Korean users who are complaining about this issue as well. We're using version 0.10.0 of draftjs. The users who have complained have been on Windows 7 and 10 in the latest Chrome version. I'm also able to reproduce this in OSX 10.11.6 and Chrome latest.

As the user is typing, unless they type a space the Korean characters do not get combined immediately. In a standard content editable div the characters are combined as you type. It seems to be a little faster in the demo editor than our application so I'll also be investigating on our side. This video demonstrates the lag in combining the characters: https://www.dropbox.com/s/6nfpokq7udhinp4/korean_typing.mov?dl=0

https://github.com/facebook/draft-js/pull/844 might help?

flarnie commented 7 years ago

Hi @doortts and @nburt - thanks for reporting this. Definitely sounds like a bug. We have some known issues with IME input. Thanks for your patience - I will look into this asap, unfortunately I've been more focused on shipping some changes to other open source libraries. Hopefully will look into this and do some general issue clean-up in the next couple of weeks.

doortts commented 7 years ago

@flarnie Thank you for your positive response. Now a days we are (seriously) considering to keep going to use draftjs or not in our product because of IME bugs. In any decision, it is sad thing to us. We hope fixed soon. If fixed, more Korean developers will be able to use (awesome) draftjs.

nburt commented 7 years ago

@flarnie I think I'll have a little time next week and will try and take a look. Do you have any ideas on what the issue could be or pointers for where I should start looking?

flarnie commented 7 years ago

Hi @nburt! Thanks for looking into this.

I have found this tool useful for logging the events that fire with IME. I have seen that browsers will go into "composition mode", where a 'compositionStart' event is followed by other events until the user finishes a word, and then you get a 'compositionEnd' event.

Draft has a whole separate set of event handlers for 'composition mode' and they live here: https://github.com/facebook/draft-js/blob/master/src/component/handlers/composition/DraftEditorCompositionHandler.js

When things work correctly, here is the general algorithm:

on 'compositionStart', switch to the DraftEditorCompositionHandler to handle events.
every time you get a 'beforeInput' event, add to a string which we are building up to represent the composition.
when we get the 'compositionEnd' event it's time to resolve the composition; we take that string which was built up and insert that into the editorState.
then we exit composition mode.

Hope that is helpful. :)

nburt commented 7 years ago

@flarnie started to dig in a little. I found that the joining lag is due to letter-spacing we're applying in a decorator that highlights all spaces in the editor. I'm wondering if this is a bug in DraftJS or an issue with our implementation.

As you can see in the below screenshot, Korean characters are inserted within the span tag of the decorator as you type. Once I hit space again ('compositionEnd'), they are broken into a new span tag. This means that until they are moved into a new tag, the letter-spacing CSS is applied and they look separated. I've also tested that the same behavior occurs with Japanese. For English, as soon as I type a character following a space it is immediately broken out into a new span (2nd screenshot).

Since the editorState isn't updated until 'compositionEnd' does that mean this is intended behavior for IME languages?

nburt commented 7 years ago

An update on this from our side:

We actually found out that for us the main issue was with our code. We had a race condition where we were sometimes updating editor state in the middle of composition (likely during the 20ms timeout here: https://github.com/facebook/draft-js/blob/master/src/component/handlers/composition/DraftEditorCompositionHandler.js#L80). We've solved the issues we had with the editor freezing up/dropping characters by delaying any state updates until after the compositionEnd event.

We still are experiencing the display problem with our decorator as I mentioned above. Should IME languages be creating a new span too?

facebookarchive / draft-js

Korean typing is so slow in Chrome browser #1102