Note: There are a few cases of duplicates in user autocompletion which are being worked on.

input event should be fired after compositionupdate

RESOLVED FIXED in mozilla12

Status

()

Core
DOM: Events
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

({dev-doc-complete, inputmethod})

Trunk
mozilla12
dev-doc-complete, inputmethod
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Keywords: dev-doc-needed
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).
Created attachment 584322 [details] [diff] [review]
Patch
Attachment #584322 - Flags: review?(ehsan)
Attachment #584322 - Flags: review?(bugs)
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.
Attachment #584322 - Flags: review?(ehsan) → review+

Updated

6 years ago
Attachment #584322 - Flags: review?(bugs) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/7fc0a1ede6a9
Whiteboard: [inbound]
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/7fc0a1ede6a9
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
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?
Depends on: 717147
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.
Depends on: 717560
Documentation updated:

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

And mentioned on Firefox 12 for developers.
Keywords: dev-doc-needed → dev-doc-complete
(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.

Updated

2 years ago
Depends on: 1166695

Updated

2 years ago
Depends on: 1167095
You need to log in before you can comment on or make changes to this bug.