This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It is not clear how CompositionEvent should behave per current draft. Should it have .locale property which is then initialized for example using the legacy initCompositionEvent? And should the dictionary for ctor have locale too? Some version of some spec (I'm getting lost with D3E, UIEvents and UIEventsExtensions) had .locale in KeyboardEvent. Anyhow, since .locale is there for initCompositionEvent, I'll add it to the dictionary too in Gecko. Guess work here.
Oh, CompositionEvent used to have readonly attribute DOMString? data, but now it is non-nullable. Why the backwards incompatible change?
I'm not following the D3E discussion lately, but ~2years ago when I investigated this, only IE was implementing the .locale on Composition events. It was hard to formulate the proper value for .locale, and I gave up including it in IME API. I'm not sure how popular the usage is, but I guess we should avoid abandon .locale in the spec as it is poorly spec'ed and quite hard or sometimes meanless to expose the value on some environment. Note: You may wonder why .locale is filled for each event, even though .locale should rarely change between events. I heard that the rationale was for not leaking user's environment without user's consent - typing on keyboard is considered an affirmative action that user let the user agent (or the author of the content) know in which locale he/she is typing text. Note2: the intention to include .locale in IME API was not only to expose user's typing environment, but to *change* the locale so that an author can *force* which language is expected to type in for some form element etc. (i.e., .locale is writable). It might sound useful, but quite hard to implement interoperably.
Now tracking as: https://github.com/w3c/uievents/issues/48