Bug 55560 – [chromium] Changing the value of an input element doesn't cancel IME composition

• Component: HTML Editing
• Status: RESOLVED WONTFIX

[Ryosuke Niwa]

Created attachment 84382 [details]
demo

On Safari, modifying the value of an input element cancels IME composition and removes the marked text.  However, on chromium, this does not happen.

See the attached demo.

[Hironori Bono]

(In reply to comment #0)
> Created an attachment (id=84382) [details]
> demo
> 
> On Safari, modifying the value of an input element cancels IME composition and removes the marked text.  However, on chromium, this does not happen.
> 
> See the attached demo.

I once implemented a change that canceled an ongoing composition when the input-element value is changed by JS. But, it caused some site-compatibility problems (especially Google Suggest). (Google Suggest replaces the text with its suggestion when typing a down key or an up key. If we cancel an ongoing composition when the input-element value is changed, it cancels the composition.)

Regards,

Hironori Bono

[Ryosuke Niwa]

(In reply to comment #1)
> I once implemented a change that canceled an ongoing composition when the input-element value is changed by JS. But, it caused some site-compatibility problems (especially Google Suggest). (Google Suggest replaces the text with its suggestion when typing a down key or an up key. If we cancel an ongoing composition when the input-element value is changed, it cancels the composition.)

This shouldn't be an issue for Japanese IME because down arrow key, space bar, etc... is always caught by IME and won't be sent to the website.  Which means that suggest won't be replacing the text until the user confirms the current composition, and I think this is a correct behavior.

Now, there's a bug in Chromium that Chinese IME doesn't stop the propagation of a down arrow key even if it's used to select a different composition candidate.  So the down arrow key used to select a different candidate causes google.co.jp to replace the input's value.  But once we fix this bug, a down arrow key used to select a composition candidate is always caught by IME, and we shouldn't have the said issue.

[Hironori Bono]

(In reply to comment #2)

> This shouldn't be an issue for Japanese IME because down arrow key, space bar, etc... is always caught by IME and won't be sent to the website.

It is up to an IME itself whether to consume these keys. That is, we can implement an IME that does not consume a down-arrow key or a space key at least on Windows. (Mac and Linux use IMEs to compose accented alphabets. These IMEs do not consume a down key, do they?)

> Which means that suggest won't be replacing the text until the user confirms the current composition, and I think this is a correct behavior.

I think this is just a matter of tastes. Some people like browsers to allow JS to replace the composition text while a user is composing text, other people not. (It seems Google suggest like to replace the composition text while a user is composing text.) It may be better to talk with JavaScript developers about it?

> Now, there's a bug in Chromium that Chinese IME doesn't stop the propagation of a down arrow key even if it's used to select a different composition candidate.  So the down arrow key used to select a different candidate causes google.co.jp to replace the input's value.  But once we fix this bug, a down arrow key used to select a composition candidate is always caught by IME, and we shouldn't have the said issue.

If I recall correctly, Chromium replaces a key code with 229 (VK_PROCESSKEY) when an IME says it handles a key event. So, if Chromium sends a key event without replacing its key code when an IME says it does not handle the key event. :)

Regards,

Hironori Bono

[Ryosuke Niwa]

(In reply to comment #3)
> > Which means that suggest won't be replacing the text until the user confirms the current composition, and I think this is a correct behavior.
> 
> I think this is just a matter of tastes. Some people like browsers to allow JS to replace the composition text while a user is composing text, other people not. (It seems Google suggest like to replace the composition text while a user is composing text.) It may be better to talk with JavaScript developers about it?

There's an ongoing thread on whatwg about this.  But I don't think Chrome's current behavior can be correct or intended.

To see the bug, open the attached test and type "nihao" with Chinese IME on Windows or Mac.  Then press down array key.  The text is replaced by henhao but "henha" is still marked and looks as if I'm compositing "henha" but if I continue to type "ma" still with IME, then I observe that "henhaomao" is shown inside the input element.

This is all because WebCore expects IME be canceling composition when selection is changed but Chrome doesn't.

> > Now, there's a bug in Chromium that Chinese IME doesn't stop the propagation of a down arrow key even if it's used to select a different composition candidate.  So the down arrow key used to select a different candidate causes google.co.jp to replace the input's value.  But once we fix this bug, a down arrow key used to select a composition candidate is always caught by IME, and we shouldn't have the said issue.
> 
> If I recall correctly, Chromium replaces a key code with 229 (VK_PROCESSKEY) when an IME says it handles a key event. So, if Chromium sends a key event without replacing its key code when an IME says it does not handle the key event. :)

It's still odd that Safari and Chrome behave differently.  In my opinion, we should match Safari's behavior at least on Mac.  If Google Suggest is broken on Safari, then it seems like Google Suggest should be fixed to work for Safari.

[Hironori Bono]

(In reply to comment #4)
> It's still odd that Safari and Chrome behave differently.  In my opinion, we should match Safari's behavior at least on Mac.  If Google Suggest is broken on Safari, then it seems like Google Suggest should be fixed to work for Safari.

I'm wondering why this bug is filed to webkit. It would be better to file this issue to crbug.com because this issue seems to be an issue of Chrome front-end.

Regards,

Hironori Bono

[Ryosuke Niwa]

http://crbug.com/105450