I noticed both Netscape 6.2 and Mozilla 0.9.9 support the following methods from the Netscape 4 event model: captureEvents, releaseEvents and routeEvent However, the support is vary bad (The URL lists the results of simple support tests) Basically, the methods must either be recreated or removed - currently, they are useless!
-> DOM Events
Assignee: asa → joki
Component: Browser-General → DOM Events
QA Contact: doronr → vladimire
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
The url is no longer any good. window and document objects still list captureEvents, releaseEvents and routeEvent functions in my tests.
> There is no DOM 2 Events equivalent to routeEvent(evt): events normally > propagate to the next element having an event listener for the same type of event. Correction: dispatchEvent(evt) is the equivalent DOM 2 Events method http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/ events.html#Events-EventTarget-dispatchEvent
Could we perhaps finally remove capture/route/releaseEvents ? (and clean up nsEventListenerManager)
I think I'd be in favor, esp. if web usage is nonexistent.. bc, do you happen to have stats on this stuff?
(In reply to comment #7) > I think I'd be in favor, esp. if web usage is nonexistent.. bc, do you happen > to have stats on this stuff? > No, sorry. How hard would it be to just rip them out of the trunk and see what the fallout is? I could do a before/after scan of the top public sites but that would still miss most "applications" in general and especially those used internally by companies. Maybe Hixie as a better answer for stats.
Unfortunatly there are quite a few pages talking about these pages, so i'd think it safe to assume it's still used. http://www.google.com/search?q=captureEvents http://www.google.com/search?q=releaseEvents Could we perhaps tweak their behaviour such that captureEvent and releaseEvents are no-ops (and issue a warning to the js-console when they are called)? captureEvents seems way more used and if we catch the events during bubbling phase anyway then in reality it's a no-op already. routeEvent is a no-op already, so either we could leave things as is, or compleatly remove it. I'd probably leave as is.
I'm resolving this bug as a DUPLICATE of bug 330494. The decision to remove support for captureEvents, releaseEvents and routeEvent functions has been made and carried out over there. See bug 330494 comment #22
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 330494
You need to log in before you can comment on or make changes to this bug.