Firechicken

Over at Mozilla.org they've been working on fixing their load events capture bug. That's great news, because Opera has had lots of trouble with sites that used event capture when they didn't intend to do so. We had the correct, spec-compliant implementation. However, web developers don't read specs. They test in browsers. We suffered the incompatibility problems because sites were written for Firefox's implementation. We've had ugly problems caused by this issue for years, on extremely important sites like AOL.com, and we've worked hard through Open The Web, information and even site patching.

Inevitably, when Firefox fixes the bug they run into those badly coded sites. They start seeing the problems we've had all along. So what do they do? They play chicken! They decide to tweak the spec to solve the problem their bugs created in the first place.

If they go for this solution, we have to follow them for compliance.

To be fair, I do think that aligning a spec to the web can be a good solution, as long as it ensures interoperability and covers the use cases. And the DOM2 Events spec itself is vague. I guess the problem is a spec that attempts to be so language-generic that it avoids referring to even the all-important JavaScript window object, it isn't clearly specified where the window object fits into the event capture/bubble model. They can and probably will argue that their implementation is DOM conformant (and make sure the HTML5/web apps spec lands on their side?).

I'm still disappointed.

13 thoughts on “Firechicken

  1. Well, sadly enough it won't be the first time a spec has been altered to match a broken browser implementation. Or even the second or third time. When implementations can ignore specs, do their own thing, and then "fix" the spec to cover up their mistakes, what ARE specs good for?

  2. It's particularly annoying since Safari worked on implementing this correctly too. Gecko would have been the last major implementation of DOM2 Events to fall into line with the spec. Instead they bail out like that 😦 . Now everybody else will have to fix their spec-compliance to be Firefox-compliant instead..

  3. If they had 1 or 2% of the market they would conform.Tipical monopolistic BS.Could you make some noise at the www-dom list, saying "bla bla bla, the spec has to become mozilla compliant because they don't want to fix their bugs bla bla bla"

  4. I have 2 questions about your thoughts.* What should currentTarget refer to?window.addEventListener('click', function(event) { alert(event.currentTarget);}, false);The DOM 2 Events spec says it should refer to "the EventTarget whose EventListeners are currently being processed". If the listener was attached to window, shouldn't currentTarget refer to window?* When should the listener be called for the HTMLDocument load event?window.addEventListener('load', listener, true);window.addEventListener('load', listener, false);If the listener is actually attached to window, and the document is a child of window, the listener should be called during the capture phase. Since the listener isn't attached to the document, and since load events don't bubble, the listener shouldn't be called during the bubbling phase.

  5. I think currentTarget should refer to the window, yes. We may run into scripts that expect a typical DOM node and break trying to do things like event.currentTarget.tagName.toLowerCase() but actually .currentTarget is used much less than .target so I wouldn't expect serious compatibility problems from this. (Though I have a proven track record of being too optimistic on whether something might cause problems! :-p )If compatibility with existing content is the name of the game (which it is unless Moz+Saf+Opera decide to go for consistency and continue the massive evangelism campaign Opera has been doing alone so far) we must ignore the "capture" argument for load events and specify a "limited bubble hack" that makes the document's load event bubble to the Window.On Digg you commented "I'd really prefer that event listeners weren't ever allowed to be attached to the window object to begin with" – indeed. I seem to remember that we support this merely because it's What Gecko Does ™. Load event listeners added to document never fire(d?) – before we ran into this problem Opera actually didn't implement window.addEventListener at all since, as we know, the window object isn't part of the DOM nor the DOM events spec…

  6. > … the massive evangelism campaign Opera has been doing alone so farI dunno how much Opera has done in comparison to everyone else, but Opera certainly isn't the only one trying to evangelize the web.> If compatibility with existing content is the name of the game … we must ignore the "capture" argument for load events and specify a "limited bubble hack"Actually, Gecko calls listeners during the capture _and_ bubbling phase for the document load event! Opera already does it wrong for compatibility, so why no go ahead and make it completely compatible? It's already bubbling the document load event up to window.The global addEventListener function is a mess, and I would prefer that it just be marked deprecated rather than trying to fix it.

  7. > Opera certainly isn't the only one trying to evangelize the webI never said or meant that. However, we've been struggling with this problem for a *long* time so naturally it annoys me to see Gecko get away with rewriting the spec like that, even when I can appreciate it from a pragmatic point of view. Hey, on both the event capture bugs [1] we have a "biggest implementor gets to rewrite spec" effect. I hope it doesn't become a Gecko habit..> The global addEventListener function is a mess..but we have no choice but trying to fix it, since it is so widely used. Thanks again Gecko.[1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 is the other one

  8. I hope it doesn't become a Gecko habit..

    you're out of luck Hallvord. I still don't understand why they didn't regressed the WRONG_DOCUMENT_ERR bug. Doesn't this one breaks sites too ?

Leave a reply to _Grey_ Cancel reply