713502 - input event should be fired after compositionupdate

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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 :-(

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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 7

[(no longer active)]

Comment on attachment 584322 [details] [diff] [review]
Patch

r=me on the editor part.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7fc0a1ede6a9

Comment 9

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/7fc0a1ede6a9

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 13

[Eric Shepherd [:sheppy]]

Documentation updated:

https://developer.mozilla.org/en/DOM/DOM_event_reference/compositionupdate

And mentioned on Firefox 12 for developers.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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

Comment 15

[Eric Shepherd [:sheppy]]

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

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thanks, I translated it to Japanese.