draft-js

draft-js copied to clipboard

Bug report

Tested environment

• Distribution: Ubuntu 18.04 (Bionic)
• Packages:

  fcitx/bionic,now 1:4.2.9.6-1 all
  fcitx-mozc/bionic-updates,now 2.20.2673.102+dfsg-2ubuntu0.18.04.1 amd64
  chromium-browser/bionic-updates,bionic-security,now 77.0.3865.90-0ubuntu0.18.04.1 amd64
  google-chrome-stable/stable,now 78.0.3904.70-1 amd64
  

• Draft-JS Commit: 5dd99d327066f5f0b30b95ab95770822cff1ac65 and prior

NOTE: Enviroment is not limited to this combination. NOTE: This gist helps setup this environment.

Reproducible steps

1. Create an simple Draft-JS editor. No need any extra changes. Even https://jsfiddle.net/gmertk/e61z7nfa can reproduce this issue.

2. Open it on Google Chrome or Chromium on Linux environment.

3. Focus it and start fcitx-mozc Japanese IME. Often it starts with Ctrl+Space.

4. Type next key sequence exactly in this order.

   n i h o n g o [space] n y u u r y o k u [space]
   

   NOTE: [space] is actual space key, but we can reproduce this behavior by using any other keys that select a candidate from the candidates list, such as down arrow key.

What is the expected behavior?

Get 日本語入力 (ni-ho-n-go-nyu-u-ryo-ku), which means “Japanese input.”

What is the current behavior?

Get 日本語有力 (ni-ho-n-go-yu-u-ryo-ku), in which it removed n, thus nyu changed to yu so get a different character.

Investigation

This is related to src/component/handlers/composition/DraftEditorCompositionHandler.js implementation.

When onCompositionEnd is called, we don’t resolve the composition immediately however, delay by the RESOLVE_DELAY timer. Right after onCompositionEnd is called, in this situation, it always calls onKeyDown. Thus it will resolve the composition on that onKeyDown event timing. However, resolving the composition at this timing seems caused this problem. If we don’t have the timer and resolving the composition at onCompositionEnd immediately, this problem is not happening.

Event sequence

Multiple onKeyDown events for many keys preceding...
...
onKeyDown for `[space]` key
onKeyDown for `n` key
onCompositionEnd : start timer.
onKeyDown for unknown (It's always called in this situation) : resolve composition.
onCompositionStart
onCompositionEnd timer fire : do nothing, because `resolved` is `true`.

Some note from my investigation

• This problem is not happening on Firefox.
• This problem is not happening on other platforms such as macOS.
• The problem is not happening in normal contenteditable div, but observe same native events in this order, includes all keydown and compositionstart and compositionend.
• The keydown event fires right after compositionend has timeStamp between previous keyDown (for n key) and compositionend, which looks weird.
• Do not have any reasonable workarounds or solutions yet I figured out without degrading behaviors on the other platform or the other language input method behaviors.
• Given specific environment, probably this is Google Chrome, Chromium or fcitx problem, however, not truly understand yet the root issue.

How this is destroying text input on browsers: https://www.youtube.com/watch?v=KOkggWX-024

What @ujihisa linked from his comment shows the first line as expected behavior (with an extra enter key after getting a first candidate by the space, I think.)

In this example, I think, he is typing using instead of Romaji input (This is what I described in the reproducible steps,) using Hiragana input. With that, we can get one Japanese character per one keydown except those characters with ゛ or ゜, which is typed following by the base character type.

So, to get で, type the base character て then type ゛, however in this example, it is right after selecting candidate. Thus, because of this problem, the base character て is removed then only ゛ remains instead of getting で.

This is another example of how this issue can affect Japanese input on the environment described.

Any update on this? Linux users' experiences are very bad because of this issue.

By disabling "Show preedits in Applications" in Fcitx configuration, Japanese input works fine in Chrome and Electron apps. If you want to try this option, try typing Ctrl+Alt+P. ...however, this setting is likely to cause discomfort for Japanese users.

That workaround can be handy to mitigate the pain until this bug gets fixed :+1: > preedits

I used to get this problem a lot, but after I added this key repeat setting, it seems like this problem doesn't happen as often anymore.

Try this workaround.

repeat_delay 300
repeat_rate 50