Ace: Duplicate string input when using Japanese input method editor on the latest Chrome version 53

[hoge1e3]

It happens when using windows 8 Chrome 53.0.2785.34 beta-m, and using Japanese input method(Google Japanse input).

For example, typing Japanese word "今日は" ( types "konnichiha" in keyboard )

• Go https://ace.c9.io/#nav=about
• Enable Japanse Input mode
• type "konnnichi" (hiragana string "こんにち" appears)
• press space ( convert hiragana to kanji "こんにち" -> "今日" )
• type "ha"
• then the string "今日" added to the editor, but the string 今日 remains also in the textarea.
• type enter, finally gets string "今日今日は"

This was not happen in older chrome version 52

[nightwing]

Seems to be a regression in chrome, setting value of textarea after composition is ignored in chrome 53+ on windows.

[hoge1e3]

Thank you for your replying.
Setting value of textarea after composition seems to be worked:
http://jsrun.it/hoge1e4/a6G2

And, I tested composition** event at the page:
http://jsrun.it/hoge1e4/so9p/

Chrome 53 emits an extra compositionupdate event (Marked as !!! below)
Is the problem will be solved by ignoring the event?

---

Result on Chrome 53:
start
update ｋ
update こ
update こｎ
update こん
update こんｎ
update こんに
update こんにｃ
update こんにｃｈ
update こんにち
update 今日 !!!
update 今日 !!!
end 今日
start
update ｈ
update は
update は
end は

---

And result on Chrome 52:

start
update ｋ
update こ
update こｎ
update こん
update こんｎ
update こんに
update こんにｃ
update こんにｃｈ
update こんにち
update 今日 !!!!
end 今日
start
update ｈ
update は
end は

---

[ghosert]

@nightwing this issue is very similar to the one I created https://github.com/ajaxorg/ace/issues/3027 maybe take some time on this issue, since once chrome 53 is released as an official version, it will impact almost all the non-ascii users like Chinese/Japanese.

@hoge1e3 let me know either if you have some findings, here is my email: [email protected]

Thanks both.

[hoge1e3]

@ghosert I have now checking the difference of the behavior between Chrome 52/53.

When compositionevent is fired, also onInput event is fired. But the order is different:
<52 : fired compositionend event follwed by onInput event
53 : fired onInput event follwed by compositionend event

The difference prevents from calling sendText function at textinput.js (In precise, calling onInput function with inComposition===false)
It may need to revise the state management on textinput.js, but the revision may effect to other browsers.

[ghosert]

@hoge1e3 as you know is there any concrete workaround or quick fix on this issue ? Based on my statistics, 80% users are using chrome, even the fix break other browsers, it seems still acceptable.

[hoge1e3]

I know it is ad-hoc fix, but I applied the follwing patch to my own project:
https://github.com/hoge1e3/jslesson/commit/7da745df681ca0a8ac3304122b89ea87be44a813

(Just calling onInput at the last of onCompositionEnd if the browser is Chrome53, I am not sure all Chrome53 have same symptoms.)

[hoge1e3]

Additional tool: onInput / onCompositionEnd order checker
http://jsrun.it/hoge1e4/q1EH
(Chrome 53 emits input -> input -> compositionend, while Chrome 52 does input -> compositionend -> input )

[ghosert]

Cool, this saves my hours, will try this either in my project, and Chrome 54 has the same issue as I tested. Will update here after I apply your changes.

[ghosert]

@hoge1e3 Your solution works perfect, just enhanced it to support the Chrome version which is greater than 53 like so:

var isChrome53PlusMatched = navigator.userAgent.match(/Chrome/(.*?)(.|s+|$)/);
var isChrome53Plus = false;
if (isChrome53PlusMatched) {
isChrome53Plus = isChrome53PlusMatched[1] >= 53;
}

...

if (isChrome53Plus) onInput();

[KennedyTedesco]

Same issue here, but just on Chrome of OSX.

[chzju]

Same problem
browser version: chrome 53.0.2785.116 (64-bit) OSX

[nightwing]

fixed by https://github.com/ajaxorg/ace/pull/3116