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

Wed Mar 2 20:06:07 PST 2011

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

--- Comment #4 from Ryosuke Niwa <rniwa at webkit.org>  2011-03-02 20:06:07 PST ---
(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.

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