55560 2011-03-02 01:03:58 -0800 [chromium] Changing the value of an input element doesn't cancel IME composition 2013-04-11 13:23:17 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All All RESOLVED WONTFIX P2 Normal --- 1 rniwa webkit-unassigned hbono ojan schenney suzhe tkent tony oldest_to_newest 360656 0 84382 rniwa 2011-03-02 01:03:58 -0800 Created attachment 84382 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. 361296 1 hbono 2011-03-02 18:52:49 -0800 (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 361308 2 rniwa 2011-03-02 19:16:44 -0800 (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. 361322 3 hbono 2011-03-02 19:57:16 -0800 (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 361326 4 rniwa 2011-03-02 20:06:07 -0800 (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. 361342 5 hbono 2011-03-02 20:38:45 -0800 (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 509289 6 rniwa 2011-11-25 16:09:46 -0800 http://crbug.com/105450 84382 2011-03-02 01:03:58 -0800 2011-03-02 01:03:58 -0800 demo set-value-on-input-ime-composition.html text/html 1261 rniwa PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8Ym9keT4KPHA+VGhpcyB0ZXN0IGVuc3VyZXMgV2ViS2l0 IGNsZWFycyBtYXJrZWQgdGV4dCBpbnNpZGUgYW4gaW5wdXQgZWxlbWVudCB3aGVuIHRoZSB2YWx1 ZSBpcyBwcm9ncmFtbWF0aWNhbGx5IHNldC4gVG8gbWFudWFsbHkgdGVzdCwgdHlwZSBpbiAibmlo YW8iIHVzaW5nIENoaW5lc2UgSU1FIGFuZCB0aGVuIHByZXNzIHRoZSBkb3duIGFycm93IGtleS4g VGhlIHRleHQgbXVzdCBiZSByZXBsYWNlZCBieSAiaGVuaGFvIiB3aXRob3V0IGNvbXBvc2l0aW9u IG1hcmtlci48L3A+CjxpbnB1dCBpZD0idGVzdCIgdHlwZT0idGV4dCI+CjxzY3JpcHQ+Cgp2YXIg dGVzdCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCd0ZXN0Jyk7CnRlc3QuYWRkRXZlbnRMaXN0 ZW5lcigna2V5dXAnLCBmdW5jdGlvbihldmVudCkgewogICAgaWYgKGV2ZW50LmtleUNvZGUgPT0g NDApCiAgICAgICAgdGVzdC52YWx1ZSA9ICdoZW5oYW8nOwp9KTsKCmZ1bmN0aW9uIGxvZyhtZXNz YWdlKSB7CiAgICBkb2N1bWVudC53cml0ZWxuKG1lc3NhZ2UpOwp9CgpmdW5jdGlvbiBydW5UZXN0 KCkgewogICAgdGVzdC5mb2N1cygpOwogICAgdGVzdC5zZWxlY3Rpb25TdGFydCA9IDA7CiAgICB0 ZXN0LnNlbGVjdGlvbkVuZCA9IDA7CiAgICB0ZXh0SW5wdXRDb250cm9sbGVyLnNldE1hcmtlZFRl eHQoIm5paGFvIiwgMCwgNSk7CgogICAgaWYgKCF0ZXh0SW5wdXRDb250cm9sbGVyLmhhc01hcmtl ZFRleHQoKSkKICAgICAgICByZXR1cm4gbG9nKCdGQUlMOiBuaWhhbyBpcyBub3QgbWFya2VkJyk7 CiAgICBlbHNlIGlmICh0ZXh0SW5wdXRDb250cm9sbGVyLm1hcmtlZFJhbmdlKCkudG9TdHJpbmco KSAhPSAiMCw1IikKICAgICAgICByZXR1cm4gbG9nKCdGQUlMOiBtYXJrZWQgcmFuZ2Ugd2FzICcg KyB0ZXh0SW5wdXRDb250cm9sbGVyLm1hcmtlZFJhbmdlKCkudG9TdHJpbmcoKSArICcgYnV0IGV4 cGVjdGVkIDAsNScpOwoKICAgIGV2ZW50U2VuZGVyLmtleURvd24oJ2Rvd25BcnJvdycpOwoKICAg IGlmICh0ZXh0SW5wdXRDb250cm9sbGVyLmhhc01hcmtlZFRleHQoKSkKICAgICAgICByZXR1cm4g bG9nKCdGQUlMOiBtYXJrZWQgdGV4dCBzdGlsbCBleGlzdHMnKTsKCiAgICBsb2coJ1BBU1MnKTsK fQoKaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikgewogICAgbGF5b3V0VGVzdENvbnRy b2xsZXIuZHVtcEFzVGV4dCgpOwogICAgcnVuVGVzdCgpOwp9Cgo8L3NjcmlwdD4KPC9ib2R5Pgo8 L2h0bWw+Cg==