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

Wed Mar 2 19:57:16 PST 2011

https://bugs.webkit.org/show_bug.cgi?id=55560

--- Comment #3 from Hironori Bono <hbono at chromium.org>  2011-03-02 19:57:16 PST ---
(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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.