Hi, Niwa-san.
On 2011/03/02 15:30, Ryosuke Niwa wrote:
On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato <[email protected]
<mailto:[email protected]>> wrote:
On Safari 5, even if textbox has IME composition string, text into
textbox can be replaced by DOM/script. But other browser's
behaviors are different, and this is no specification when textbox
has composition string. Although IE, Chrome and Opera keep
composition string after value is replaced by DOM, each behavior
is different.
This is the result for this test on each browsers. When textbox
has IME composition string such as ABCDEFG, then script
(textbox.value = "123";) is called, textbox becomes...
1. "123ABCDEFG" (ABCDEFG keeps composition state and caret is
after G).
2. "123" (composition string is removed).
3. "ABCDEFG" (ABCDEFG keeps composition state and caret is after G).
Which behavior is right? 1 is Opera 11, 2 is Safari 5, and 3 is
Chrome 10 and IE9.
You must have tested Chrome improperly. We currently have a bug in
Chrome. 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.
Once this bug is fixed, Chrome's behavior should match that of Safari 5.
Do you think Safari's way (ex. 2) is right? I found some bugs on
Chrome (and IE and Opera) when I test this, but I am not interesting
about bugs.
It is confused that each Web browser is different behavior for this .
This is not good as interoperability. So I would like to decide the
right behavior/specification when textbox.value = 'x'; that it has
composition string.
Also, some people says that it should not be canceled/removed even if
value is changed by DOM. Because composition string is un-committed string.
Niwa-san and folks, how do you think right design for this situation??
-- Makoto Kato
