Uh, the difference is Chrome is usually right. Dealing with Firefox bugs is starting to feel like dealing with IE. Favorite example: a 9 year old bug where a select's option menu will render in the wrong location if there's a transform in the DOM above it (https://bugzilla.mozilla.org/show_bug.cgi?id=455164)
I just tried reproducing that bug. It's fixed in multiprocess Firefox, which is the default configuration for most users. It'll be the only configuration a few months for now, once add-ons that are not multiprocess-compatible are no longer supported.
Also, Chrome is not usually right in my experience. A lot of times they don't even manage to implement the specs they themselves write correctly... Then someone else has to come along and file bugs on them, and maybe they fix them. Sometimes.
All of which is anecdote. Actual data would be much better, of course.
It doesn't matter if it's fixed in some configuration of Firefox; point is it shouldn't take nine years to fix an app-breaking bug. Even early 2000's IE had a better track record than that. It's not like this is the only instance either, here's a 17(!) year old issue about Firefox not supporting option's label attribute: https://bugzilla.mozilla.org/show_bug.cgi?id=option-label
Could you specify some issues you ran into on Chrome that affected user space this directly or took anywhere near this long to fix? I've been doing all of my development in Chrome for ~6 years and have done very, very few Chrome-specific workarounds. On the other hand, I ran into both the Firefox bugs mentioned in the last half year.
> point is it shouldn't take nine years to fix an app-breaking bug
It depends on priorities, obviously. That bug was fixed in various cases that were most-commonly hit (e.g. translate-only transforms) much earlier than now. Fixing it in the scale case more or less required completely rewriting how <select> is implemented, and there was always other stuff that needed to get done that was a bigger problem in practice.
I'm not saying this is good, obviously; it would be great if there were more people working on Gecko bugs and triage were not so critical. But there weren't and it was. I'm sorry that it's caused you problems; I'll see if I can get some progress to happen on the option label thing.
> Could you specify some issues you ran into on Chrome that affected user space this directly
Note that all these bugs were filed in the WebKit bug system for a while before I went and refiled them in the Blink bug system after Blink forked off from WebKit. So they are much older than the dates you see on those reports.
A lot of those issues are from 2008 (that's when Google Chrome launched) and hence means that have been there since the beginning and most of them affect user interaction.
Throwing dirt doesn't help anyone. If you have the skills and time, contribute a browser of your choice.
I'm not expecting Firefox to be perfect, nor do I think it's a particularly bad browser. I'm specifically trying to point out why web devs are generally accepting of Chrome's dominance when they previously rebelled so hard against IE. The answer is it's not monoculture that's the problem, it's the quality of the technology the monoculture is based on -- and I think it's clear that Chrome is by far the best modern browser to develop against. I don't think you'll find anything in that bug list that's even close to the severity of a missing feature that's supported in every other browser as far back as IE8.
> I don't think you'll find anything in that bug list that's even close to the severity of a missing feature that's supported in every other browser
You mean like not supporting high-contrast themes on Windows, literally the first thing on the list at https://bugs.chromium.org/p/chromium/issues/detail?id=92 ? Not a problem for web devs obviously, just for users, which I guess is partly your point.
Or the lack of sane text rendering behavior, having to at best opt into ligature support, if you can get them at all, etc? That's something they finally fixed recently, after 8+ years of it being a problem.
Or missing MathML support? Granted, some other browsers are pretty bad on this too.
Seriously, there's lots of stuff Chrome couldn't and can't do that other browsers can do. They're just much better (not least due to spending way more money on it) at steering web devs to never try the things Chrome is bad at and focus on the things the Chrome dev team has been focusing on...
> I don't think you'll find anything in that bug list that's even close to the severity of a missing feature that's supported in every other browser as far back as IE8.
Yes, you will. Take the border-collapse bug I mentioned: it doesn't affect other engines, to my knowledge. Border-collapse goes back to, like, IE5.
That's not even in the same league as either of the Firefox issues I've referenced. The first is actually app-breaking (in our case users couldn't see any of the select options) the second is just plain IE-level of stubbornness. I'm not saying Chrome is perfectly immaculate, just trying to explain why it's so popular among the dev community in a way FF/IE are not.
I find problems in Gecko much less often than I find problems in Blink. For example, WebKit handles border-collapse by drawing borders on top of one another, which is totally bogus when transparent borders are involved. While not a spec violation per se, Blink's behavior when absolute containing blocks are split across multiple lines is really bizarre (objects parented to that containing block just disappear). WebKit violates the HTML spec when the top margin of an element at the top of the document is queried in quirks mode. Etc. etc.
