Chrome: Multi-byte Japanese chars entry not working properly after line-break

[agirma@…]

1. go to ​http://ckeditor.com/demo
2. Change IME(input method editor) to Japanese
3. in CKE, Shift+Enter
4. type aa(ああ)

Expected: display ああ Actual: displays あああ

This only happens in Chrome(I tested in Version 37.0.2062.94) and cke enterMode = CKEDITOR.ENTER_BR

[agirma@…]

seems something to do with the filling character when editMode is <br/>

Removing the filling character(type "a" then backspace) then typing aa(ああ) won't result the same issue.

[Jakub Ś]

I have been checking this issue on Chrome 38.0.2125.111 m as this is current version at the time of writing.

Results are the opposite (only one あ is displayed instead of ああ ) but there is simply something wrong. Problem can be reproduced in Blink browsers from CKEditor 4.4.4.

To reproduce:

1. Open replace by code sample
2. Focus editor, change susyem language to Japanese and input method to Hiragana
3. Put Cursor anywhere you like e.g. After main header Apollo 11^ and press Shift+Enter
4. Type aa(ああ)

Expected: display ああ Actual: displays あ

[Jakub Ś]

A follow up to that issue.

It turns out that after seeing actual result which is あ there is no possibility to use input helper.

You press 'a' and see character あ underlined but after you press 'a' one more time the underline is gone and there is no possibility to get input helper. You need to focus some other window e.g. other browser window to get it working again ( In my case focusing FF helped:) )

[Piotrek Koszuliński]

By a careful bisecting I was able to find... rather nothing. However, I've got few observations. First of all, this issue is reproducible when the filling char (ZWS) is present. Second, the filling char is not removed while typing. Third, the behaviour changed at least twice during works on 4.4.4. First in ​git:d2a570d, then in ​git:e6b42a417. This code seems to be unrelated, but my guess is that frequency of editor#getSnapshot method calls changes. This leads as straight to the code which juggles the filler (see selection.js), but it still gives us pretty much nothing regarding where and how to approach fixing this issue. Most likely, a research is needed to understand how to handle IME in the clipboard or selection.js, so we could also understand where and if this issue may be fixed.

[Artur Delura]

The problem was caused by modifying an element text content while composition. It was done ​here. Chrome don't like such situation so it rejects composition changes. That's why we couldn't see second あ character. What I did is to prevent modifying an element text content by preventing onKeydown method in the undo plugin. See ​commit. Further informations are ​here.

Changes and tests in ​branch:t/12597.

[Piotrek Koszuliński]

The issue was fixed, but there's a problem with undo/redo. I reported the issue I spotted in #12823. There's also #12391 for IEs.

[Piotrek Koszuliński]

Fixed on master with ​git:f6cbb24.

[Piotrek Koszuliński]

BTW. I think that we can create a manual TC for this issue. It will simply be ignored by testers who can't change the language. We'll need manual tests anyway in the much more complex #12823 and #12391 which you said Artur yourself, that thoroughly testing automatically would be madness.

[Artur Delura]

Written manual test for issue in ​commit:9ce1403.