Remove captureEvents, releaseEvents and routeEvent functions from window and document objects

VERIFIED DUPLICATE of bug 673919

Status

()

P3
normal
VERIFIED DUPLICATE of bug 673919
17 years ago
6 years ago

People

(Reporter: jorishuizer, Assigned: joki)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
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

Comment 2

17 years ago
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

Comment 3

14 years ago
The url is no longer any good.

window and document objects still list captureEvents, releaseEvents and
routeEvent functions in my tests.
Keywords: qawanted

Comment 4

14 years ago
As far as I can see...

captureEvents: it is not "implemented" in phase capture; it works but when
bubbling up the document containment hierarchy. So that is wrong or just not
implemented accordingly. captureEvents() should behave like 

objectReference.addEventListener("[event type]", functionName, true);

but it does not.

Reference:
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/guide/evnt.html#1010131

releaseEvents: it should behave like 

objectReference.removeEventListener("[event type]", functionName, true);

but it does not.

routeEvent: the event propagates regardless of that method.
"The routeEvent() method provides one way to direct the course of the event once
it has passed through its intercepting event handler. Calling routeEvent()
causes the browser to look for another object which is capturing this same
event. Remember that only three objects can capture events -- window, document,
and layer -- so the next object must be one of the remaining two, in order of
the pecking order stated earlier."
http://www.wdvl.com/Authoring/JavaScript/Events/routing.html

" Description [on routeEvent]
If a [window] sub-object (document or layer) is also capturing the event, the
event is sent to that object. Otherwise, it is sent to its original target."
Reference:
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/window.html#1203352

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. 

I propose to remove these captureEvents, releaseEvents and routeEvent functions
from window and document objects and to update Gecko DOM reference and
corresponding sections of http://developer-test.mozilla.org/docs/Gecko_DOM_Reference
regarding their DOM 2 Events replacements.

Resummarizing accordingly; URL updated
Keywords: qawanted
Summary: Mozilla has support for the Netscape 4 event model, but it's very buggy → Remove captureEvents, releaseEvents and routeEvent functions from window and document objects

Comment 5

14 years ago
> 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?

Comment 8

13 years ago
(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.

Comment 10

12 years ago
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
Status: RESOLVED → VERIFIED

Updated

6 years ago
Duplicate of bug: 673919
You need to log in before you can comment on or make changes to this bug.