This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23258 - Consider composition event order relative to IME API info when choosing to update DOM after compositionupdate...
Summary: Consider composition event order relative to IME API info when choosing to up...
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-16 21:42 UTC by Travis Leithead [MSFT]
Modified: 2013-12-04 01:37 UTC (History)
2 users (show)

See Also:


Attachments

Description Travis Leithead [MSFT] 2013-09-16 21:42:47 UTC
I previously thought it would be good to change the compositionupdate event to fire before the value of the input element is changed in the DOM.

However, in an internal review around the IME API, it seems we may want to reconsider this.

The scenario is that the IME API introduces additional information that can be observed during an IME composition. This information includes (but is not limited to) the character indexes where the active composition is taking place, the current candidate window placement or exclusion rectangle, etc. It is expected that web developers will interact with the IME API during a composition, primarily those triggered by compositionupdate events. If the DOM is not yet updated until after compositionupdate fires, then usage of the IME API (relative to the content in the DOM) will be slightly out-of-date (to be refreshed in the DOM immediately after compositionupdate is finished dispatching.

A suggestion in the current IME API is to possibly include some of the state-full information on the composition events themselves, but we should probably have a discussion on this.
Comment 1 Travis Leithead [MSFT] 2013-12-04 01:37:34 UTC
IME API has substantively changed and this needs to be re-reviewed in light of that change.