Closed
Bug 256333
(dom3_events)
Opened 20 years ago
Closed 2 years ago
Implement DOM 3 Events
Categories
(Core :: DOM: Events, enhancement, P5)
Core
DOM: Events
Tracking
()
RESOLVED
INVALID
People
(Reporter: ilya.konstantinov+future, Unassigned)
References
()
Details
This is a tracker bug for the implementation of DOM 3 Events ifaces.
Reporter | ||
Updated•20 years ago
|
Alias: dom3_events
Reporter | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•20 years ago
|
Status: ASSIGNED → NEW
Reporter | ||
Updated•20 years ago
|
Assignee: events → mozilla-bugzilla
Reporter | ||
Comment 1•20 years ago
|
||
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 ;)
Reporter | ||
Comment 2•20 years ago
|
||
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•20 years ago
|
||
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.
Updated•15 years ago
|
QA Contact: ian → events
Comment 5•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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.
Updated•6 years ago
|
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
Comment 8•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: ilya.konstantinov+future → nobody
Comment 9•2 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•