Just lodged my first bug for Opera, only to figure out 5 mins after I hit submit that its not a bug with Opera, Its a bug with every other browser.

Seems that in Opera 8.5 when you use addEventListener with capture set to true, it behaves differently to the other common browsers that use addEventListener which are Safari and Mozilla.

On further examination (see below) its conceivable that Opera is the only one to follow the spec.

Here is my testcase for it

Try the CAPTURE example (the second test from the top)  First run it in Firefox or Safari, then Opera.

Try any of the ‘MIXED’ tests that capture on more than one element MIXED4, MIXED5, MIXED6, MIXED7 or MIXED8 and compare behavior with Safari and Firefox which follow the w3 spec.

Now From the spec, note the bit in bold…

Event capture is the process by which an EventListener registered on an ancestor of the event’s target can intercept events of a given type before they are received by the event’s target. Capture operates from the top of the tree, generally the Document, downward, making it the symmetrical opposite of bubbling which is described below. The chain of EventTargets from the top of the tree to the event’s target is determined before the initial dispatch of the event. If modifications occur to the tree during event processing, event flow will proceed based on the initial state of the tree.

An EventListener being registered on an EventTarget may choose to have that EventListener capture events by specifying the useCapture parameter of the addEventListener method to be true. Thereafter, when an event of the given type is dispatched toward a descendant of the capturing object, the event will trigger any capturing event listeners of the appropriate type which exist in the direct line between the top of the document and the event’s target. This downward propagation continues until the event’s target is reached. A capturing EventListener will not be triggered by events dispatched directly to the EventTarget upon which it is registered.

If the capturing EventListener wishes to prevent further processing of the event from occurring it may call the stopProgagation method of the Event interface. This will prevent further dispatch of the event, although additional EventListeners registered at the same hierarchy level will still receive the event. Once an event’s stopPropagation method has been called, further calls to that method have no additional effect. If no additional capturers exist and stopPropagation has not been called, the event triggers the appropriate EventListeners on the target itself.

Although event capture is similar to the delegation based event model in which all interested parties register their listeners directly on the target about which they wish to receive notifications, it is different in two important respects. First, event capture only allows interception of events which are targeted at descendants of the capturing EventTarget. It does not allow interception of events targeted to the capturer’s ancestors, its siblings, or its sibling’s descendants. Secondly, event capture is not specified for a single EventTarget, it is specified for a specific type of event. Once specified, event capture intercepts all events of the specified type targeted toward any of the capturer’s descendants.

The bit in bold disturbs me, because I don’t think Safari or Firefox obeys this and if I am right then I suspect that Opera may in fact be the only one to obey the spec properly.

Going back and looking at the test case, if you click on an element that has a listener added with capture, it is not triggered- as per the spec.

Compare MIXED2 and MIXED3. Its spot on as the spec describes