Pressing enter key doesn't make new line.

[ellemedit]

I'm new to draft-js. I found a problem while testing and using it.
Because this rich text editor doesn't make new line in Korean.
I have to press enter twice as aforementioned. It's really inconvenience.
This situation is also being happened in Facebook Note and Messenger.

If this was intended to prevent mistake during type, It should be fixed or changed.
When user press enter, line should be changed.

My test environments was OSX latest, Chrome latest.

[ellemedit]

I tested more:

• Chrome needs enter twice
• Safari works well. best.
• FireFox similar to Chrome.
• Opera similar to Chrome.

And I found new bug.

Chrome, FireFox and Opera are even bad at removing CHOSEONG.
CHOSEONG(초성) is first step of writing Korean.

Below is the full-step writing Korean.

ㄱ -> 가 -> 갑 -> 값

When I try to remove first-step word, it need to press delete 3 times.
Removing 2, 3 and 4 step word works correctly.

It happens production of Facebook Note and Messenger.

[hellendag]

Are you using OSX El Capitan?

[ellemedit]

@hellendag Yes, it is latest version

[hellendag]

Thanks. There are some known issues with Korean composition that appear to have been introduced by El Capitan. I'll follow up here with details.

[ellemedit]

@hellendag I saw it is working well at Windows. It can't be fixed in OSX El Cap?

[hellendag]

Here's the crux of the issue. See the screenshot below, the result (in Chrome 49) of testing on https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html with the following steps:

• Switch to 2-set Korean keyboard
• Type d (ㅇ)
• Press backspace to delete the character.

The events occur from the bottom (oldest) to the top (newest).

Note the compositionEnd and textInput events. The data field here should be the empty string -- the character is being removed after pressing the backspace key, so the events should not carry the ㅇ character in the data field.

The Draft composition handler expects that deletions do not preserve the deleted character in the textInput event data field for this reason. While OSX versions prior to El Capitan behaved correctly, it's broken now. Note that this bug occurs on Firefox and Safari as well -- it appears to be an OS-level issue. Windows does not have this problem.

We may be able to devise a workaround, but the problem here would be that we won't know the difference between a committed composition and a deleted one. When textInput fires, the backspace key has not yet been handled, so there would be no detectable difference between a deletion and a confirmation. We could defer handling the textInput until after some key event, in order to detect whether it's a deletion or a commit. But that's kind of a hack.

The most appropriate thing here is probably for us to file an issue with Apple.

[ellemedit]

@hellendag I see. Even if I pressed delete, data still consist composited word in OSX El Cap.
Can I suggest about it?
I saw Draft works well on OSX El Cap Safari. I checked the event occurs.

There's no composition type events. I think Draft doesn't need composition types....
Only textInput, input, keydown and keyup events are not enough to implement Draft composition handler? Is it for other language?

[hellendag]

Hmm. Something is very wrong with Korean input on El Capitan.

I just tried this in Safari and ran into a bunch of different weird event sequences when switching language to Korean or reloading the page, including both yours and mine.

• Initially, I saw something that looked like your screenshot: no composition events, no textInput event. (This is unequivocally wrong.)
• I switched to Katakana and typed a test string. Composition events appeared properly.
• I then cleared the input and switched back to Korean. Characters didn't even get inserted into the input, though key events fired. No composition or textInput events fired.
• I reloaded the page and typed Korean characters. Everything then worked the same as in my screenshot, with composition events and the incorrect data field.

[doortts]

@hellendag IMHO, biggest problem using draft.js with Korean is 'enter key event problem' which already mentioned by @beingbook.
So, how about change to insert hardcoded newline when last event was ''compositionupdate'' and not 'compositioned"?
Then (I think ) it will be good enough.

[flarnie]

Hi - following up on this, it sounds like the original bug reported was an issue with Korean IME in all browsers in El Capitan. The only action item is:

The most appropriate thing here is probably for us to file an issue with Apple."

Since we don't have a solution for fixing this within Draft I'm closing this issue. Please reopen if you would like to propose a work-around.