[Webkit-unassigned] [Bug 31902] Webkit modifies the DOM after the compositionend event

[bugzilla-daemon at webkit.org]

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


James Su <suzhe at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |suzhe at chromium.org




--- Comment #1 from James Su <suzhe at chromium.org>  2010-03-16 21:45:59 PST ---
(In reply to comment #0)
> All DOM changes resulting from IME composition should be strictly bounded
> between compositionstart and compositionend events
How the DOM will be changed by a compositionend event? For now, a
compositionend event will only update the composition text (the text being
selected). If the following textInput event is cancelled, the composition text
will be left unconfirmed. See chrome issue: http://crbug.com/30982 for
reference.

The current spec states that composition events can be cancelled. Are you plan
to modify the spec to make them non-cancellable? IMHO the semantic of
cancelling these events is confusing and may not be possible to be implemented.

> 
> Please see here, using either Linux or Windows IME:
> http://www.danilatos.com/event-test/ExperimentTest.html
> Use any Webkit that supports composition events, e.g. Chrome 4 or Webkit after
> http://trac.webkit.org/changeset/50968/trunk
> (Note, I haven't updated the test page to show the compositionupdate event yet,
> but this is not particularly relevant).
> 
> Also note that, if the composition is not cancelled, i.e. if there is to be a
> textInput event as well, then we get a 2nd compositionstart/update/end cycle
> after the normal one, where the content is basically deleted and re-inserted. I
> think this is bad too (but webkit has been doing this for a while).
I tested it on Chrome Linux with SCIM input method, but didn't encounter the
2nd composition cycle issue. See following sample event sequence of inputting
"啊" with Chinese pinyin input method: (D=keydown, U=keyup, CS =
compositionstart, and so on.)

D 229 0 false false false
CS 啊
U 65 0 false false false
D 229 0 false false false
CU 啊
CE 啊
T 啊
U 32 0 false false false

So I believe the 2nd cycle issue is caused by the input method, rather than the
webkit.

And following is the sequence of cancelling a composition:

D 229 0 false false false
CS 啊
U 65 0 false false false
D 229 0 false false false
CE 
U 27 0 false false false

In this case, webkit doesn't fire compositionupdate event before the last
compositionend event, which is different than the behavior described in the
current spec:
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-compositionupdate


> 
> A few possible ways to fix:
> a) Simply ensure compositionend gets fired after the last dom change (don't
> fire it and then change the dom once more).
We need to clarify how the DOM will be changed by compositionend.

> b) Same as (a), but to avoid the 2nd round of composition events, have
> textInput come before compositionend. That way when textInput is triggered, the
> content has been removed so textInput is still a preview of what is about to be
> inserted (if that is in fact desirable, I'm guessing that would be why webkit
> deletes then re-inserts the content)
Semantically, a textInput event is actually a result of a confirm composition
action (compositionend with a non-empty text), so it would be confusing if
textInput events are fired after compositionend events.

> c) Same as (a), but to avoid the 2nd round of composition events, *and* still
> have textInput fire after compositionend, stop the deleting and re-inserting of
> content. Instead, textInput is just informational and happens after-the-fact
> (thus cancelling it has no effect).
The spec states that the textInput event can be cancelled. And it may be
useful. See chrome issue: http://crbug.com/30982 for reference, which is
actually a webkit issue.

> 
> b) is preferred by Hironori (cc'd) and me, but contradicts the current DOM
> Level 3 spec, which says textInput must come after compositionend. That said,
> hbono and I are involved with that part of the spec (and he drafted it), so
> based on our implementation experience it could very well be worth trying to
> change the spec while it's still fresh.
> 
> This issue is also tracked at:
> http://code.google.com/p/chromium/issues/detail?id=28246

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