Closed Bug 9544 Opened 21 years ago Closed 14 years ago

[FEATURE] captureEvents() method doesn not work.


(Core :: DOM: Core & HTML, defect, P3)






(Reporter: desale, Assigned: joki)



(Keywords: testcase, Whiteboard: [ADT need info][TESTCASE] window.captureEvents() must be implemented (or is not working))


(2 files)

Method window.captureEvents() is returning undefined. So either its not
implemented or not working.

PRODUCT: Seamonkey [Apprunner/Viewer]
BUILD: 07-08-08.
OS: Win95, WinNT, Win98, MacOS.

1] Please copy code I'm providing. Save as HTML file.
2] Open this HTML file in Apprunner as well as Viewer.
3] You'll see the return value of window.captureEvents() getting printed on

NOTE: In actual code [testcase] the method is used without parantheses in order
to know what it is exactly.

window.captureEvents() = function captureEvents() { [native code] }

window.captureEvents() = undefined


<title>Test Page</title>
<form name="workform">
document.writeln("window.captureEvents() = ");

Whiteboard: [TESTCASE] window.captureEvents() must be implemented (or is not working)
desale's testcase cannot be simplified further. Updated Status to "[TESTCASE]
blah" standard.
Assignee: vidur → joki
An event problem for Tom Pixley.
Summary: Method window.captureEvents() is not working or not implemented. → captureEvents() method not implemented.
Same thing is happening with document.captureEvents(), so it means this method
not implemented for any object.
Changing Summary.
*** Bug 13342 has been marked as a duplicate of this bug. ***
*** Bug 12930 has been marked as a duplicate of this bug. ***
Target Milestone: M13
Summary: captureEvents() method not implemented. → [FEATURE] captureEvents() method not implemented.
Target Milestone: M13 → M14
Moving M14.
Target Milestone: M14 → M13
Moving 4.x event system features back to M13
Target Milestone: M13 → M14
Well the 4.x event stuff is done but its untested.  Given that I had to make
several changes to general event handling I think I'll take the conservative
road this time and save this till the tree opens for M14.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Should be fixed now, modulo any weird compatibility stuff my testing missed.
Closed: 21 years ago
Resolution: --- → FIXED
Verified with 2000-02-17-08.
The captureEvents() method is *implemented* now, but it doesn't appear to
*work*.  (at least not in Moz. 0.8.1)  Perhaps this bug needs to be reopened.
The attached testcase shows that the event handler is being triggered during
event bubbling rather than as a true event capture.

Note that there are substantial incompatibilities between Netscape 4 capturing
and DOM capturing (for example capture events in NN4 don't propagate by default
but they do in the DOM.)  Instead of struggling to get the compatiblity just
right, you could also make the executive decision to formally renounce the
Netscape 4 event capturing model.
joki, according to David Flanagan's comments & the testcase provided by David, 
I'm re-opening this bug.
Changing Summary of the bug.
any thoughts joki ?
Resolution: FIXED → ---
Summary: [FEATURE] captureEvents() method not implemented. → [FEATURE] captureEvents() method doesn not work.
Nominating this one for nsbeta1. method is working wrong way, so backward 
compatibility of javascript is getting defeated.
Keywords: nsbeta1
ADT triage team would like to know what user-visible problems this is causing.
Whiteboard: [TESTCASE] window.captureEvents() must be implemented (or is not working) → [ADT need info][TESTCASE] window.captureEvents() must be implemented (or is not working)
This bug will matter when user wants to create his predefined "Event Handlers" 
on certain events. Please see testcase attached by David Flanagan which shows 
how it could be used.
we're too close to 1.0 for this.
Keywords: nsbeta1nsbeta1-
Target Milestone: M14 → mozilla1.1
Nominating again for RTM.
Keywords: nsbeta1-nsbeta1
captureEvents is not necessary for mozilla. 

onclick = function(e){alert(e);};

captureEvents(Event.CLICK) does nothing.

This feature has a problem with event capturing object detection script. Consider:

// IE/Opera stuff.
else if(window.captureEvent){
  // NS4 stuff.


Please un-implement captureEvents.

alert(window.captureEvents) // "undefined" in mozilla
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
ccing people who know the event system....

Is there a good reason for us to keep this function defined if it does nothing
It's a question of what breaks more. The fact that the method is there but does
nothing, or that the method isn't there at all and causes code that calls it to
stop running alltogether when it tries to call it. It's a hard call, I don't
know the answer, but given that I don't see any URL's to any real sites that are
broken due to this, I think I'd rather leave it as is.
Well, if it's supposed to do nothing, could we document that and change it
accordingly?  At the moment it goes and sets flags and stuff; it's just that
those flags don't seem to affect anything....
>given that I don't see any URL's to any real sites that are
>broken due to this, I think I'd rather leave it as is.

The proverbial "If it ain't broke, don't fix it"


Things can always be improved.

captureEvents is part of the NS4 event model. I think it should not be included
in Mozilla as a do-nothing placeholder feature. Removing captureEvents would
probably not break any sites. If it did, then I'd say those sites are pretty
poorly programmed. Moreover, such sites are damned lucky to get their ns4 code
to work with Mozilla.

The domref docs document captureEvents and releaseEvents. This should cease.

Comment 21 was prompted from a problem I had. I was developing a script to work
in as many browsers as possible and I was quite surprised when Mozilla was
executing the captureEvents code. I found that Mozilla had tested positive for
captureEvents and decided to report the problem, but first I searched the
bugzilla database and found this.

By eliminating captureEvents, the source code for this feature would not need
maintenance. Eliminating detritus from programs is a good thing, right?
I've updated bug 132132 before noticing this bug. 

captureEvents (and releaseEvents and routeEvent) was not working according to NS
4 specs as soon as NS 6.1. Therefore, we're speaking of absence of support or
inadequate support for at least 5 years with new releases. We're now in an era
where Opera 7+, Safari 1.x, Mozilla 1.x and Firefox 1.x support DOM 2 events,
not the old (9 years old, deprecated) NS 4.x event model. Even attachment 38685 [details]
does not work as expected to NS 4.x specs in Opera 8 final release.

IMO, the decision to make is obvious here. FWIW, handleEvent() is no longer
listed in any object and has been replaced everywhere needed by DOM 2 Events
I am resolving this bug as DUPLICATE of bug 330494. In bug 330494 at comment #c22, you'll see that the patch drops support for captureEvents() and that a semi-convenient message is displayed in the error console.

Please do not reopen this bug: this bug is really a duplicate of bug 330494. 
Thank you.
Closed: 21 years ago14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 330494
Verified.  Nice catch!
You need to log in before you can comment on or make changes to this bug.