I realized that two compatibility issues of composition event handling. 1. at compositionupdate event handler, <input>.value returns old value on Gecko and WebKit, but IE returns new value. 2. input events are fired during composition on IE and WebKit, but we don't dispatch them. And input event handler on WebKit can get the newer value of the composing editor. So, web developers cannot get newer value on Gecko. I think that we should fire input event during composition too.

Hmm, there are a lot of input event handlers in chrome. I think that we need to change most of them. These handlers shouldn't process during composition. E.g., if the handler changes the editor's size or content, IME is committed forcibly. It breaks IME's behavior. We can take one of following 3 ways for fix this issue: 1. Add MozIsComposing attribute for DOM Input event which returns TRUE if it's fired during composition. (Or inputMethod attribute like textinput of D3E?) 2. Gets the target editor element in each handler, and check if IME is composing. Like this: http://mxr.mozilla.org/mozilla-central/source/mobile/xul/chrome/content/forms.js#296 3. Dispatch "inputwithoutcomposition" event or something and handle it instead of new "input" event. #3 is ugly, I don't like to do this, it's the safest way though. #2 might be difficult to get the target editor in some handlers. And the code looks a little bit complicated. #1 might be better, however, it adds the non-standard attribute to the event. And input event is now using nsUIEvent and nsDOMUIEvent. So, we need to create a new internal event struct and a new DOM event implementation. Smaug, how do you think about this?

input event handlers: http://mxr.mozilla.org/mozilla-central/search?string=addEventListener%28\%22input\%22&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central http://mxr.mozilla.org/mozilla-central/search?string=event%3D\%22input\%22&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central There might be other handlers, but they will be found by testers if so :-(

And I worry that our UI developers may create new IME related bugs if they don't know about the problem (composition is forcibly committed by some actions in input handlers) after this bug is fixed.

Hmm, contrary to my expectation, I have not found any problems with patched build without any changes of input event handlers. I think I don't need to change them for now. I'll post a patch soon. Sorry for the spam comment (comment 1).

FYI: The nsTextEditListener is the only observer of edit actions, some add-ons might be so too, though. http://mxr.mozilla.org/mozilla-central/ident?i=AddEditorObserver&filter=

Comment on attachment 584322 [details] [diff] [review] Patch r=me on the editor part.

Created: https://developer.mozilla.org/en/DOM/DOM_event_reference/input Updated: https://developer.mozilla.org/en/DOM/DOM_event_reference/compositionupdate They need some help of native English speakers.

Hmm, I realized that why the input events during composition don't cause any regressions in chrome. By the patch, the input events are fired as untrusted events because "text" event handler doesn't make nsAutoEditorKeypressOperation instance. I write a patch which makes nsAutoEditorKeypressOperation in the stack at text event handler. Then, I can see some regressions in chrome UI. I think whether trusted or untrusted event is not checked by web pages, therefore, the new input events also useful for web pages. Therefore, I don't think that the patch should be backed out from m-c. How do you think, smaug?

Well, looks like you got patches to fix chrome and make the event trusted. I think there is still time to fix that all before FF12 goes to Aurora.

Documentation updated: https://developer.mozilla.org/en/DOM/DOM_event_reference/compositionupdate And mentioned on Firefox 12 for developers.

(In reply to Eric Shepherd [:sheppy] from comment #13) > Documentation updated: > > https://developer.mozilla.org/en/DOM/DOM_event_reference/compositionupdate > > And mentioned on Firefox 12 for developers. Thank you, sheppy. Could you check input event document too? https://developer.mozilla.org/en/DOM/DOM_event_reference/input

I cleaned up the input article a bit. Looks good to me.

Thanks, I translated it to Japanese.