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

[bugzilla-daemon at webkit.org]

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

           Summary: Webkit modifies the DOM after the compositionend event
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
               URL: http://www.danilatos.com/event-test/ExperimentTest.htm
                    l
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Major
          Priority: P2
         Component: HTML Editing
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: daniel.danilatos at gmail.com
                CC: hbono at chromium.org


All DOM changes resulting from IME composition should be strictly bounded
between compositionstart and compositionend events

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).

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).
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)
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).

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.