Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate string input when using Japanese input method editor on the latest Chrome version 53 #3045

Closed
hoge1e3 opened this issue Aug 1, 2016 · 12 comments
Labels

Comments

@hoge1e3
Copy link

hoge1e3 commented Aug 1, 2016

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
Copy link
Member

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

@hoge1e3
Copy link
Author

hoge1e3 commented Aug 2, 2016

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 k
update こ
update こn
update こん
update こんn
update こんに
update こんにc
update こんにch
update こんにち
update 今日 !!!
update 今日 !!!
end 今日
start
update h
update は
update は
end は


And result on Chrome 52:

start
update k
update こ
update こn
update こん
update こんn
update こんに
update こんにc
update こんにch
update こんにち
update 今日 !!!!
end 今日
start
update h
update は
end は


@ghosert
Copy link

ghosert commented Aug 4, 2016

@nightwing this issue is very similar to the one I created #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: ghosert@gmail.com

Thanks both.

@hoge1e3
Copy link
Author

hoge1e3 commented Aug 8, 2016

@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
Copy link

ghosert commented Aug 9, 2016

@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
Copy link
Author

hoge1e3 commented Aug 10, 2016

I know it is ad-hoc fix, but I applied the follwing patch to my own project:
hoge1e3/jslesson@7da745d

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

@hoge1e3
Copy link
Author

hoge1e3 commented Aug 10, 2016

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
Copy link

ghosert commented Aug 10, 2016

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
Copy link

ghosert commented Aug 23, 2016

@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
Copy link

Same issue here, but just on Chrome of OSX.

@chzju
Copy link

chzju commented Sep 19, 2016

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

wuxc pushed a commit to openatx-archive/atx-webide that referenced this issue Sep 21, 2016
@nightwing nightwing added the ime label Sep 28, 2016
wujunchuan added a commit to wujunchuan/Surfingkeys that referenced this issue Oct 5, 2016
jpallen pushed a commit to jpallen/ace that referenced this issue Oct 11, 2016
@nightwing
Copy link
Member

fixed by #3116

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants