Last Comment Bug 235441 - Capture event listeners fire on target (?!)
: Capture event listeners fire on target (?!)
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 9 votes (vote)
: ---
Assigned To: Olli Pettay [:smaug]
Depends on: 234455
Blocks: 242763
  Show dependency treegraph
Reported: 2004-02-24 08:35 PST by Hixie (not reading bugmail)
Modified: 2013-04-04 08:13 PDT (History)
28 users (show)
ian: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

TC with IMG as capture target (1.06 KB, text/html)
2005-10-19 04:23 PDT, Hallvord R. M. Sten
no flags Details
proposed patch (4.20 KB, patch)
2006-05-26 06:24 PDT, Olli Pettay [:smaug]
no flags Details | Diff | Splinter Review
patch (40.54 KB, patch)
2007-07-24 15:16 PDT, Olli Pettay [:smaug]
no flags Details | Diff | Splinter Review

Description Hixie (not reading bugmail) 2004-02-24 08:35:36 PST
   1. Attach a capture listener to an element.
   2. Fire an event on the element.

   Listener is called.



This works in Opera. (o125100)
Comment 1 Boris Zbarsky [:bz] 2004-02-24 11:48:10 PST
>   Nothing.

Why?  That's not what the DOM events spec says, as far as I can tell.
clearly says:

  Each event has an EventTarget toward which the event is directed by the DOM
  implementation. This EventTarget is specified in the Event's target attribute.
  When the event reaches the target, any event listeners registered on the
  EventTarget are triggered.

and the capturing listener is certainly an event listener registered on the
EventTarget here.
Comment 2 Hixie (not reading bugmail) 2004-02-24 11:50:37 PST
But it also clearly says (wherever you look up "capturing") that capture event
listeners are only called during the capture phase, and that the capture phase
is only done to the target's ancestors.
Comment 3 Hixie (not reading bugmail) 2004-02-24 11:53:18 PST
And as far as I can tell, the quoted sentence above has been removed from DOM3
Events. See, in particular, this section, which I think is pretty explicit:
Comment 4 Boris Zbarsky [:bz] 2004-02-24 11:53:37 PST
Ah, interesting. It does say:

  A capturing EventListener will not be triggered by events dispatched directly to
  the EventTarget upon which it is registered.

I wonder whether this is an event retargeting issue.  That is, since the
original target is the textnode....
Comment 5 Hixie (not reading bugmail) 2004-02-24 12:23:00 PST
This bug was originally found on an image onclick.
Comment 6 Boris Zbarsky [:bz] 2004-02-24 14:40:20 PST
Ah, good.  Saves me writing a testcase.  ;)

This should really just get fixed as part of bug 234455...
Comment 7 WADA 2005-10-16 14:59:22 PDT
*** Bug 242763 has been marked as a duplicate of this bug. ***
Comment 8 Hixie (not reading bugmail) 2005-10-18 09:28:04 PDT
(FWIW I've received complaints from people about this.)
Comment 9 Hallvord R. M. Sten 2005-10-19 04:23:23 PDT
Created attachment 200066 [details]
TC with IMG as capture target

A TC with IMG for Boris since I had one lying around :-)
Comment 10 Olli Pettay [:smaug] 2006-01-24 09:24:26 PST
How should we handle this when the element has an XBL binding and event is 
originated in the anonymous content?
Comment 11 Anne (:annevk) 2006-01-24 15:28:25 PST
If this is something you want to give feedback on you can do so on <>. The Web APIs WG is currently taking care of DOM Level 3 Events.
Comment 12 Olli Pettay [:smaug] 2006-03-12 13:19:36 PST
(In reply to comment #10)
> How should we handle this when the element has an XBL binding and event is 
> originated in the anonymous content?
hixie or jonas, any comments to this?
Comment 13 Jonas Sicking (:sicking) PTO Until July 5th 2006-03-13 03:14:30 PST
It would be great if you could raise an issue with the webapi WG on this. From a logical point of view I can see both behaviours being useful, and mozs current behaviour less confusing. But compat with the DOM L2 spec would be bad to break for this.

Again, please raise an issue on the public list.
Comment 14 Jonas Sicking (:sicking) PTO Until July 5th 2006-03-22 19:47:40 PST
I raised the issue with the webapi WG:
Comment 15 Maciej Stachowiak 2006-03-23 23:02:16 PST
In the discussion it was discovered that DOM Level 2 Events unambiguously states that listeners registered with useCapture = true should not fire in the target phase, and that the DOM Level 2 Events test suite actually checks this.
Comment 16 Boris Zbarsky [:bz] 2006-03-23 23:12:13 PST
So sounds like we should fix this... and audit all the addEventListener calls in our chrome that add capturing listeners.
Comment 17 Olli Pettay [:smaug] 2006-03-24 07:50:59 PST
But what to do with XBL? (comment #10)
Comment 18 Olli Pettay [:smaug] 2006-05-26 06:24:34 PDT
Created attachment 223434 [details] [diff] [review]
proposed patch

If we want to do this, it should happen before 1.9a1, imo.
This may cause some regressions in chrome, but those should be easy to 
fix. Dialog buttons were the only ones I found easily.
(I'll go through all the addEventListener calls)
Comment 19 Olli Pettay [:smaug] 2006-05-26 07:48:06 PDT
Comment on attachment 223434 [details] [diff] [review]
proposed patch

hmm, better to check all the addEventListener calls first
Comment 20 Olli Pettay [:smaug] 2006-05-27 13:30:31 PDT
There is though this one:
Comment 21 Olli Pettay [:smaug] 2006-06-22 00:49:18 PDT
If/when fixing this, remember to check that Bug 342011 works too.
Comment 22 Jonas Sicking (:sicking) PTO Until July 5th 2006-10-12 16:01:47 PDT
Marking as blocking, we need to decide what to do here. We don't follow the spec, but it's known that if we fix it sites will break.
Comment 23 Joao Eiras 2006-10-15 21:46:34 PDT
> Marking as blocking, we need to decide what to do here.
> We don't follow the spec, but it's known that if we fix it sites will break.

Sites already break in Opera and in Safari when it didn't fired capturing event listeners in target.
The fix for the websites code is trivial - just make sure the proper documentation is then supplied to the authors.
This change should be listed in the changelog in bold.
Comment 24 Olli Pettay [:smaug] 2007-06-15 12:12:36 PDT
jst, jonas, bz, what should we do with this?
If we decide to fix this, I can sure do it and fix all the callers in
We could perhaps take the fix and during a6 test how many sites 
break. The fix is after all just setting a simple flag in event dispatcher and something similar in nsDOMEvent::GetEventPhase, so backing it out is easy.
Though, I'm a bit worried that this might break quite many sites.
Comment 25 Jonas Sicking (:sicking) PTO Until July 5th 2007-06-15 12:32:12 PDT
Yeah, testing this in alpha6 might not be a bad idea. Though i suspect we're not going to get that much testing until we release a beta.

I would really like to see us comply with the spec, and since the spec isn't going to change it seems likely that we would have to :(

Basically we should try to evangelize sites that break because of this, and figuring out which ones those are is best done by simply fixing this bug...

Interested to hear other peoples opinion.

Would it be possible to warn in FF2 every time we actually fire a capturing listener on the target? That seems like a good way of getting people to start fixing their code.
Comment 26 Boris Zbarsky [:bz] 2007-06-15 13:04:30 PDT
For what it's worth, I still think that as the spec is written it makes it difficult to attach a capturing listener on a subtree, because it won't fire for the root of the subtree.  But if the spec is really not going to change, I guess that's just life.  Not the first suboptimal thing in a spec...
Comment 27 Aiko 2007-06-15 13:37:58 PDT
You could take a look at Opera's browser.js where they are fixing some sites abuse of capturing listeners with a few lines of JavaScript. Apparently the main problem is sites are using window.addEventListener("load", ..., true). Since the DOM events spec doesn't cover the window object anyway it might make sense to make an exception for this case.
Comment 28 Hixie (not reading bugmail) 2007-06-16 18:13:28 PDT
The DOM specs do now cover the 'window' object:

Indeed, they explicitly say that the 'load' event does not fire at the 'window' object. I don't remember why we excluded the 'load' event, though.

bz: I do not remember hearing that argument (subtrees) brought up in the discussion. Could you bring it up on the group and see why the group wants to not allow it? I don't remember the arguments.
Comment 29 Boris Zbarsky [:bz] 2007-06-17 10:48:05 PDT
> bz: I do not remember hearing that argument (subtrees) brought up down near the bottom.  Starting with "One advantage of interpretation A..."

I don't think this point was actually seriously discussed.  In fact, I see no serious discussion in that whole thread, really.

I don't really have time to follow an e-mail thread in the next month or so; someone else would have to bring it up if something more than the initial post is expected.
Comment 30 Hixie (not reading bugmail) 2007-06-17 11:40:52 PDT
I did some research for you. As far as I can tell the reasoning was that Safari and Opera did the no-capture-at-targets behaviour, and that matched the spec. However, Safari has since been forced to change back to the Gecko behaviour of firing capture handlers at targets for compatibility with Web pages. So maybe you should just ignore this bug until the spec changes...
Comment 31 Boris Zbarsky [:bz] 2007-06-17 13:40:21 PDT
For what it's worth, I do think we could do what Opera does -- have a permanent bubbling load listener on Window that enumerates the capturing load listeners and dispatches the event to them, and not fire capturing listeners at target.  That would be fully spec-compliant as far as I can see, and I suspect that would lead to very little breakage.
Comment 32 Jonas Sicking (:sicking) PTO Until July 5th 2007-06-18 01:40:18 PDT
The subtree argument has been brought up several times iirc. Basically there are use cases for behaving either way. Ideal would have been if the argument was a bitfield rather than a boolean...
Comment 33 Olli Pettay [:smaug] 2007-06-20 08:52:36 PDT
There is still the issue mentioned in comment #10. 
Right solution for that would be probably, but unfortunately that
breaks lots of existing bindings in ff chrome.
Comment 34 Hallvord R. M. Sten 2007-06-21 01:05:05 PDT
Clarification: I believe capturing load events for window and capturing events on target are two separate issues. This bug is only about the latter issue (so my browser.js patches are irrelevant really).

At Opera we've had greater real-world problems with window load events and relatively few problems with following the spec for capturing listeners at target (think I've seen about a bug a year on it - now one of the problems was at so you may want to fix that :-) ).

I think you should fix this bug. The spec for the window object is written carefully to be bug-compatible with Gecko not capturing load events on target, but what this bug is about is already spec'ed in detail in DOM2 Events, which is not likely to change.
Comment 35 Hallvord R. M. Sten 2007-06-21 01:07:30 PDT
(should have said "Gecko not capturing load events on *window*")
Comment 36 Hixie (not reading bugmail) 2007-06-21 02:06:37 PDT
Given that Safari was forced to switch to the capture-on-target behaviour, it seems that there is some argument to say that the spec _should_ change. And it could change easily, we just need to say that it's changed and that's it...
Comment 37 Jonas Sicking (:sicking) PTO Until July 5th 2007-06-21 12:00:24 PDT
How do you propose we get the spec changed? Last time I tried it was deemed too incompatible change compared to DOM Events L2
Comment 38 Hixie (not reading bugmail) 2007-06-21 12:48:56 PDT
You'd have Apple's support, now.
Comment 39 Hallvord R. M. Sten 2007-06-22 01:25:42 PDT
AFAIK WebKit was "forced" to change to non-standard behaviour by one single site - Getting them to fix it should not be too hard, we know whom to talk to. (They were however concerned that the issue might cause problems on other Atlas-powered sites. I don't know if that is the case.)
Comment 40 Olli Pettay [:smaug] 2007-07-09 15:00:44 PDT
This wouldn't be as simple change as I first thought. Handling XBL1 (comment #10) and native anonymous content in some reasonable way needs bigger changes.
We could leave XBL1 alone, but the handling of native anonymous content
would have to be fixed.
Comment 41 Jonas Sicking (:sicking) PTO Until July 5th 2007-07-09 15:24:13 PDT
Like i said before. I don't really care how XBL1 behaves, as long as we don't break any XUL widgets. Same thing applies to native-anon content really.
Comment 42 Olli Pettay [:smaug] 2007-07-09 15:33:48 PDT
Native anonymous is more important IMO, because that means basically form 
elements. Handling mousemove for example should be consistent everywhere, it
shouldn't depend on whether the element has native anonymous content or not.

Comment 43 Olli Pettay [:smaug] 2007-07-24 15:16:23 PDT
Created attachment 273663 [details] [diff] [review]

Fixes the bug, also with native anonymous content (but not with xbl).
Some changes to chrome and mochitests are needed. 
This is possibly too late for 1.9, but better to have at least the
full patch to help evaluation whether we really want this for 1.9.
Comment 44 Jonas Sicking (:sicking) PTO Until July 5th 2007-09-20 15:32:00 PDT
I think we decided that we did not want to do this since it risks breaking too many sites?

Anyone opposed?
Comment 45 Jonas Sicking (:sicking) PTO Until July 5th 2007-09-25 18:45:14 PDT
Comment on attachment 273663 [details] [diff] [review]

Removing request for now. Smaug, feel free to mark this one WONTFIX, or rerequest review if you think we indeed want this.
Comment 46 WADA 2007-09-25 19:16:44 PDT
If WONTFIX, question of Bug 242763 will revive;
  (A) eventPhase property value when event target object
      "2"(Target Phase) was set in both event for true and for false.
  (B) Order of event scheduling was as follows when event target object 
      1.event handler, 2.event listener(true), 3.event listener(false)
I think following oreder/value is reasonable when event target object.
  1. event listner(true) with "Target Phase"
  2. event handler of the event target object
  3. event listener(false) with "Bubble Phase"
Comment 47 Jonas Sicking (:sicking) PTO Until July 5th 2007-09-25 19:35:48 PDT
Yes, if we WONTFIX this bug reopening that bug seems like a reasonable thing to do.
Comment 48 Olli Pettay [:smaug] 2007-09-27 06:09:29 PDT
I don't think we want this for 1.9. Would break too many sites.
But perhaps removing blocking1.9+ would be enough, and leave this open
for moz2.
Comment 49 Jonas Sicking (:sicking) PTO Until July 5th 2007-09-27 10:57:18 PDT
Comment 50 Colby Russell :crussell (no longer Mozilla-ing) 2012-06-07 10:23:36 PDT
A note, since the spec has changed since the last bug activity:

(In reply to Maciej Stachowiak from comment #15)
> In the discussion it was discovered that DOM Level 2 Events unambiguously
> states that listeners registered with useCapture = true should not fire in
> the target phase, and that the DOM Level 2 Events test suite actually checks
> this.

The spec is less unambiguous today than it was then.  Between the 2009 and 2010 revisions,[1][2] the spec was changed so that the description of the useCapture parameter says:

    If true, useCapture indicates that the user wishes to add the event
    listener for the capture phase and target only, i.e. this event
    listener will not be triggered during the bubbling phase. If false,
    the event listener must only be triggered during the target and
    bubbling phases.

That section is (almost) identical in the most current revision today.  The addEventListener description itself still suggests the old behavior:

    Registers an event listener, depending on the useCapture
    parameter, on the capture phase of the DOM event flow or its
    target and bubbling phases. 

1. <>
2. <>

Note You need to log in before you can comment on or make changes to this bug.