The Firefox problem - QuirksBlog

In recent weeks Firefox 4 beta 1 and Opera 10.60 were released, and I could also put my hands on a working Chrome 4. I added all these browsers to the compatibility tables, which are now all updated, except for the Events one.

There’s little difference with my earlier reports, except that the new Firefox beta is making a serious effort to support the background module. It’s not there yet, but Firefox is not as disastrously behind as it was a month back.

Firefox

Of course Firefox remains a pain in other respects: still no support for contains(), incorrect indexing of attributes (it’s essentially random), no innerText or outerHTML, no sane second argument for the add() method for select boxes, a colorDepth of 24.

All these bugs are Firefox-only, with the exception of the attribute indexing, which is also a problem in IE. Frankly, I’m starting to get fed up with Firefox and its haughty refusal to implements useful methods and properties found in all other browsers. But maybe that’s a passing phase. Maybe I’ll pick another browser to be annoyed at next time around.

Events

I haven’t yet updated the Events table, partly because it’s such a lot of work (it takes me as much time as all other tables combined), and partly because I do not expect huge changes. I tested various problems in IE9, and sadly found no improvements.

I’m not sure when I’ll have the time to do the Events table; I hope before I leave on holiday in early August.

Comments

1 Posted by Mathias Bynens on 20 July 2010 | Permalink

Considering Chrome's forced auto-update policy, what's the point of testing Chrome 4?

2 Posted by Markus Stange on 20 July 2010 | Permalink

You say that Firefox "refuses" to implement all those features you listed. That sounds like you asked the Firefox developers to do it and got "no" as an answer. Is that the case?

Communication with Firefox developers happens through https://bugzilla.mozilla.org/ so I've searched it for the issues you mentioned. I didn't find any bugs for contains(), add() and the attribute indexing issue, but I did find https://bugzilla.mozilla.org/show_bug.cgi?id=343357 for innerText (it suggests using textContent instead) and https://bugzilla.mozilla.org/show_bug.cgi?id=92264 for outerHTML (which mentions that it's now part of HTML5, so it has a good chance of being implemented).

The fact that I didn't find bugs for things you consider a "pain" confuses me. It could of course mean that I didn't search properly, but it could also mean that these things aren't important enough to developers to get them to file bugs about them. Or it could mean that nobody reports these things even though they're important to them. That would be a rather sad situation. How do you explain this?

3 Posted by Markus Stange on 20 July 2010 | Permalink

Also, about the colorDepth issue: In http://www.quirksmode.org/blog/archives/2010/06/more_ie9_goodne.html#c14366 you said that it's "not really important", but now you list it as a pain. Why?

And as I said over there, 24 is following the spec, so if you think it should be changed you should probably try to get the spec changed first.

4 Posted by Dave Hulbert on 20 July 2010 | Permalink

@ppk, nice work. Have the Firefox bugs you mention been reported? Would be nice to link to them if they have been.

Do you use anything like Selenium for testing the browsers? It would be cool to be able to run your tests in my own browsers too.

@Mathias, Chrome only auto-updates when you run it. You could have kept it running for a couple of years. Theoretically.

5 Posted by Spudley on 20 July 2010 | Permalink

Firefox is losing a lot of ground to Chrome lately in terms of numbers of users, and it's things like this which are driving the exodus.

The Mozilla people need to wake up and deal with the issues that are starting to annoy people.

The one that's *really* annoying me at the moment is the lack of text-overflow:ellipsis -- incredibly useful in real-world apps and it would be so easy for them to do, but they just aren't interested.

6 Posted by kangax on 20 July 2010 | Permalink

@Spudley

Is it really "so easy for them to do"?

https://bugzilla.mozilla.org/show_bug.cgi?id=312156#c66

And where is "not interested" coming from? I don't see this bug being closed as wont-fix. I see it as work in progress.

7 Posted by Matt Brubeck on 20 July 2010 | Permalink

To be fair, you should note that there are very useful features like calc() that Firefox 4 implements but WebKit does not. Or maybe you just don't test those features yet, and so your tests are stacked against Firefox?

About some of the other complaints:

http://bugzil.la/221981 - implement content pseudo-class :contains()

"add" is hard to search for in Google/Bugzilla. What specification is it in?

I couldn't find a bug about attribute indexes. If you'd like to see this fixed, can you submit one? A test case or an explanation of use cases is helpful but not required.

8 Posted by Matt Brubeck on 20 July 2010 | Permalink

calc() in Firefox: http://hacks.mozilla.org/2010/06/css3-calc/

calc() in WebKit: http://bugs.webkit.org/show_bug.cgi?id=16662

9 Posted by Trevor Norris on 20 July 2010 | Permalink

innerText is IE's implementation of the actual W3C standard of textContent. Which Firefox happily supports. You can't hold Firefox responsible for not using something that isn't part of the standard.

10 Posted by John A. Bilicki III on 20 July 2010 | Permalink

outerHTML, really? It's a proprietary Microsoft method and even if it's added to a spec that refuses to enforce open source codecs it doesn't make it an actual standard. Stick to using W3C DOM methods. I don't see Mozilla being at fault with this one.

11 Posted by Sander on 20 July 2010 | Permalink

@Matt Brubeck: I suspect ppk means the DOM Level 3 Core's contains() function - http://www.quirksmode.org/dom/w3c_core.html#t121 -, rather than the CSS3 Selectors :contains() pseudo class selector, which was dropped from the spec many years ago, and which would _really_ surprise me if it'd been implemented by IE, Webkit and Opera while I wasn't looking. (I once wrote one of the horribly naive :contains() patches in the bug you linked to, before it was explained to me why a practical (e.g. decently performing) implementation of that selector wasn't really feasible.) :)

As for why contains() isn't supported: It looks like no one has ever filed a bug on its lack, and so the developers probably aren't aware of it.

12 Posted by Peter on 21 July 2010 | Permalink

Ever since Google Chrome got released people realize that Firefox isn't the fastest anymore. Internet Explorer 9 beats it in terms of JavaScript speed, Chrome is overall faster and the new Firefox 4 interface is mostly based on a combination of Chrome and Opera.

Some things shouldn't need bugs. Developers of browser software (and more importantly: rendering engines) should be at the bleeding edge of standard development. The should be aware of the developments and changes in the standards. When quickly listing the editors of various CSS specifications, the presence of Firefox is far behind these of Microsoft, Apple and Opera.

"There isn't a bug for it" should never be an excuse. Firefox still supports CSS syntax like "border-radius-bottomright" to the annoyance of many developers. And they damn well know that. No browser is perfect: neither is Firefox.

13 Posted by Matt Brubeck on 21 July 2010 | Permalink

The DOM Level 3 spec explicitly says that Node.attributes[index] does not need to be in order:

"Objects contained in an object implementing NamedNodeMap may also be accessed by an ordinal index, but this is simply to allow convenient enumeration of the contents of a NamedNodeMap, and does not imply that the DOM specifies an order to these Nodes." http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1780488922

Node.contains() is non-standard; PPK posted a one-line implementation of it in 2006 that will work in any standard-compliant browser: http://www.quirksmode.org/blog/archives/2006/01/contains_for_mo.html

It seems that add() refers to HTMLSelectElement.add(element, index), another non-standard extension which could be trivially implemented in script using standard methods.

That's not to say that Gecko will never implement these features, but we try to prioritize features that (a) are standardized, or (b) web developers tell us they need for specific use cases that aren't easily handled by standard methods. If you think that these fall under (b), please file a bug and explain why. Or even better, propose these spec changes in the right working groups, so the behavior *is* standard and documented.

14 Posted by David Baron on 25 July 2010 | Permalink

My response on the colorDepth issue: http://dbaron.org/log/20100725-colorDepth

15 Posted by Tyler Downer on 26 July 2010 | Permalink

@Peter, every change in the software of mozilla requires a bug. Whether to add a new feature, fix and existing one, or improve something, it requires a bug id number. So, to say it shouldn't require a bug doesn't make sense, because if there is not a bug number, then there can be no change.

16 Posted by Jonas Sicking on 26 July 2010 | Permalink

Firefox developers are humans too, not mind readers :)

We are quite involved in the various standards groups, however the features you are asking for mostly seem to be IE proprietary ones. We certainly don't mind implementing IE-invented features, however there are so many of them that we could never possibly implement them all (VML anyone?). Hence we need to hear from developers which ones they think make sense.

Generally people communicate to us using bugzilla. If you prefer to simply send email, feel free to send me one and I'll forward to the appropriate person and do the bug filing myself.

Also feel free to blog about what you think we should implement. However please include enough details so that we actually know what is being asked for.

As several people has pointed out, we support .textContent which is the standardized version of innerText. I expect that IE9 previews supports this property too. Is there a reason why you couldn't use this?

As for attributes, the specifications explicitly state that they are unordered. The fact that we change the order on them allows us to perform certain performance optimizations which I would imagine that you wouldn't want to be without.

I'll defer to david on the colorDepth issue.