W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [whatwg] set input.value when input element has composition string

From: Makoto Kato <m_kato@ga2.so-net.ne.jp>
Date: Thu, 03 Mar 2011 19:47:03 +0900
Message-ID: <4D6F71A7.60808@ga2.so-net.ne.jp>
To: Ryosuke Niwa <rniwa@webkit.org>, "Kang-Hao (Kenny) Lu" <kennyluck@w3.org>
CC: WHAT Working Group <whatwg@whatwg.org>, WWW International <www-international@w3.org>, WebApps Working Group <public-webapps@w3.org>
Hi, Niwa-san.

On 2011/03/02 15:30, Ryosuke Niwa wrote:
> On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato <m_kato@ga2.so-net.ne.jp 
> <mailto:m_kato@ga2.so-net.ne.jp>> 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
Received on Thursday, 3 March 2011 10:49:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC