256333 - (dom3_events) Implement DOM 3 Events

Status: RESOLVED INVALID

(Core :: DOM: Events, enhancement, P5)

Description

[Ilya Konstantinov]

This is a tracker bug for the implementation of DOM 3 Events ifaces.

Comment 1

[Ilya Konstantinov]

Just to keep you updated:
I have most of the code ready. The changes span a bit farther than I planned,
since I realized that 'textInput' is a separate event type, and that it doesn't
have a matching 'ontextInput'. Currently my Mozilla is misbehaving, but it could
as well be something that'll be resolved by a rebuild.
Next thing I'll need to sort out what to do with event namespaces (which I
effectively ignored for now).
And then I could post the first patch. Maybe even next week.

I doubt we'll get this into 1.8 though ;)

Comment 2

[Ilya Konstantinov]

Status report:

Looks like I successfuly converted all the code not to use "on" prefix in event
names (but still use it in JS handler names, of course). Now events without
matching JS handler, such as textInput, can rightfully exist.

Also fixed the crasher which held me back. Valgrind saved the day. Turns out
some of the event names (without the "on" prefix) doesn't have a pre-registered
atom. For now, I use do_GetPermanentAtom to register it once I need it. I wonder
if I should bother registering it on startup.

Next in order: Implementing namespaces.

Comment 3

[Darin Fisher]

FWIW, it may be extremely unwise to modify any of the interfaces mentioned in
bug 275220 since those were mistakenly added to the Gecko SDK.  People are told
that they can use anything in the Gecko SDK and expect compatibility with future
versions of Gecko.  (Admittedly, they are told that they have to look for
"@status FROZEN" in the IDL file, but they are likely to overlook that for any
interface that we included in the Gecko SDK.)  Now, we are in an unfortunate
situation where we either have to break that "rule" or continue to support the
old interfaces indefinitely, which I'm sure will suck.

Comment 5

[Victor Costan]

Correct implementation of textInput is an important first step in doing advanced processing with IME input. If you're not convinced of its importance, please take a look at this application: http://nextlang.com

Comment 6

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

Not sure why you need textInput. compositionend and checking the
value of the inputted text should probably be enough.

But yes, we should implement textInput and other (not-yet-implemented) parts of DOM 3 Events.

Comment 7

[Victor Costan]

Thank you! I used those hints to build a workable solution for my situation. 

It's sad to code a Firefox-specific workaround though... I thought I'll be able to avoid workarounds by not supporting IE.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 9

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

I don't think this bug is useful. There is no such thing as DOM 3 Events anymore. The relevant specification work is happening in DOM and UI Events specs.