> Firefox, on Linux at least, is busted. It’s busted so bad that it’s painful to use. And it’s been this way ever since Firefox 3 launched — three years ago.
This is an odd statement, considering that many Firefox devs run Linux. I'm running Firefox on Linux right now, and it works great.
I guess the author of the article is hitting a specific bug. It isn't a general issue that affects all users of Firefox on Linux.
Sure, the impact of any specific bug is limited--but the gestalt of Firefox is of a development process that values press and feature creep over performance and correctness.
I haven't looked back since switching to Chrome. FF ignored obvious bugs for years. X pixmap freeing? Open since 2004. [1] I waited for six years, having to restart my browser every few hours, because it would leak over 2 GB from having a network graphs page open. Startup time? Last time I opened it, six months ago, FF took over 10 seconds to start, cold. Chromium snaps open in under a quarter second.
Then there's developer friendliness. Writing extensions is a complete mess, especially compared to Chrome. Configuration structure is haphazard at best. Profile corruption is a thing. I don't understand how a multi-million dollar foundation can tolerate this kind of experience.
> Sure, the impact of any specific bug is limited--but the gestalt of Firefox is of a development process that values press and feature creep over performance and correctness.
I'm not sure if you are just trolling or not. Assuming not, then since Firefox's development is done in the open, I assume you have some evidence for this - meeting notes or such that show that? Or some other evidence?
The evidence to the contrary seems overwhelming. Firefox's main focus in 4.0 was on performance, see arewefastyet.com for JS, and the major rewrite of the graphics system (Layers) that lets it use things like Direct2D on Windows as just two examples. And as a consequence of those huge efforts, Firefox just won Toms Hardware's speed test, beating Chrome, Opera, IE and Safari,
First, my information is about a year out of date. I only used FF (well, Mozilla Suite/Galeon/Phoenix/FF) from around 2001-2010, and it's clear the FF team has moved to improve performance since then. Perhaps my impressions from that time frame are no longer valid, but the issues I checked in Bugzilla while writing my post seemed largely unresolved.
"This is an easily-demonstrated bug that "renders" (so to
speak) many pages unusable, or forces designers to impose
kludgey Javascript 'fixes' for Firefox users. This bug has
been around for many versions, and has been mentioned many
times.
Please, please someone on the Firefox team -- take on this project."
It's not just FF: https://bugzilla.mozilla.org/show_bug.cgi?id=12916 is still unresolved, after eleven years, despite a hundred dollar bounty. Bugzilla is full of wontfix/worksforme legal wrangling where users unable to write the patches themselves (and having dealt some with FF's internals, I understand why) are told that their bugs don't matter.
Meanwhile, FF expanded from its stripped-down, single-purpose origins into a memory-consuming beast. On my Linux machines, it crashed daily. I would much rather see crashes, leaks, and slowdowns addressed before building new systems like the Awesomebar, tabs-in-titlebar, phishing prevention, and so forth.
Every developer I know has switched to Chrome. When I ask about it, I hear common rationales: speed, robustness, parsimony.
Does that clarify my criticism? There's a lot of great code in Firefox, but I don't think we should paper over the holes in the software or its development culture.
Aphyr, every single browser engine has longstanding bugs; it's just a matter of priorities.
WebKit doesn't have load events for stylesheets either, for example. It has buggy CSS selector matching, on purpose (doing the right thing was deemed too slow). There are multi-year-open bugs in V8 and Chrome, and that whole project hasn't even had an open bug database for more than a few years.
So I'm not sure the development culture is any different. You just haven't had a chance yet to file a bug and get it ignored by the WebKit folks for a few years. It happens all the time....
You're absolutely right; I've been bitten by chrome/webkit bugs as well, some of which remain unpatched. And Chrome's relative youth means the browser code hasn't acquired the same level of cruft--so I can't strongly infer a difference in process.
> First, my information is about a year out of date. I only used FF (well, Mozilla Suite/Galeon/Phoenix/FF) from around 2001-2010
Oh, ok. The last year was a big year for FF performance: There have been huge gains in speed and reductions in memory usage. FF4 began that, and FF7, 8 and 9 take it even further.
Given that you are talking about the time period before that, I can understand more where you are coming from - performance was a lesser priority then compared to other features. Thanks for clarifying that.
They now fire `load` events on stylesheet loads? Awesome! Shameful it’s been that way for so long. I’ve seen terrible work-arounds like always just firing a faux-load event 100ms after the stylesheet was added to the page, in the wild.
He made a valid and extended argument, one can read and agree or disagree with.
You isolate just a phrase from it and call him on "trolling"?
In general, internet discussions would be much much better if "troll" and "FUD" weren't used to disqualify arguments we don't like (or, maybe weren't used, period).
To throw around comments like "but the gestalt of Firefox is of a development process that values press and feature creep over performance and correctness" - that's textbook flamebait. It's a direct insult to Firefox developers and fans, and its only result will be to start an argument. So it's a natural suspicion that he might be trolling.
In any case, I gave a reasoned response, giving him the benefit of the doubt that he isn't trolling. But if he was, I guess I was wasting my time.
I do agree with you: Internet discussions would be much better if we did not use "troll", "FUD", "flamebait", etc., but also if people did not act in those ways.
> To throw around comments like "but the gestalt of Firefox is of a development process that values press and feature creep over performance and correctness" - that's textbook flamebait.
Sure, but it can also be his honest opinion, that he came to by comparing, say, the minimal changes between Chrome versions and the more evolved FF updates. What I'm saying is, the entirety of his comment matters to see if it's "trolling" or not, not just a juicy quote.
You're right, the rest of the comment was not so bad, and that's in his favor. He could have avoided the flamebait sentence and I would have politely disagreed but had no issue with his comment.
> the gestalt of Firefox is of a development process that values press and feature creep over performance and correctness.
:
> I've recently been running into a number of "benchmarks" where some rendering engines achieve better performance by simply doing the wrong thing because the right one would be "too slow". […] This is not exactly an isolated incident; a number of the performance issues I've run into recently in Gecko have had to do with correctly handling edge cases that this particular open-source engine happens to just not handle.[1]
I run FF on linux for dev work (not on FF itself, but for JS heavy web apps). Actually, I run a whole bunch of different FF versions with different profiles for testing a huge variety of things.
My main gripe is that some of the extensions (NoScript, Firebug and friends) sometimes break things, hog the CPU in one way or another or just plain eat up the heap.
I am fine with this. These are extensions, after all and it's for dev stuff, which I judge by a slightly different standard than 'normal user' stuff.
The latest FF releases especially make me happy because they're adding modern web features and working on UX and performance. And it shows and feels.
I don't care about bookmarks because I don't bother storing those in the browser anymore. Was the choice for storing 'stuff' in SQLite a good one? Yes of course it was. It's the best cross-platform way to store structured data on disk, which is why everybody and his/her dog has made the same choice. Are there inefficient ways in which it is being used? Maybe. Probably? I haven't looked into this, but this is hardly an insurmountable problem.
Sure it felt like FF was lagging behind once the WebKit browsers started coming out (with better JS engines) but the Mozilla Team is back in the game with its new release cycles and updates.
Well that's nice for you that it works, usually works for me at home.
I run about 200 desktop linux machines and sqlite locking is a common problem on firefox. Users are often completely unaware of how to fix even though they are quite technical.
The problem here is that Places (along with lots of other places in our code) still creates and uses synchronous database statements. SQLite is only threadsafe because it serializes all access to a database connection (this is unlikely to change any time soon).
To make this problem worse, every time we "fix" an area that does this, we end up putting more work on the background thread, which increases the likelihood that the remaining places that need to acquire the mutex on the main thread will encounter contention for the mutex.
Some of you might recall we hit this problem in the run-up to Firefox 4 as well (November/December of last year), and it caused Marco and I to have to reachitect a bunch of stuff in Places for a few months in order to work around it. Until Firefox removes all uses of the synchronous Storage API from the main thread, this issue will keep rearing it's head. (When that happens we can actually use SQLite in a way that stops using mutexs and will likely speed it up too.)
Hmm, from reading the thread it does not appear to have been solved, at least not the underlying problems. What was solved was the removal of a couple of synchronous calls. The fact that there are slow queries on some profiles seems to have been caused by the fact that ANALYZE does not run for some people[1], and this does seem like it has been fixed yet. I should check this for my Firefox profile at work to see if old stats are the reason for it hanging.
So what needs to be fixed ,if I follow that thread, is the removal of all synchronous calls and some solution to either not have to run ANALYZE or run it more often.
Perhaps FF devs have super-beefed-up machines (required to compile FF) that average users don't, and therefore don't see many of the performance problems that average users do?
I run Firefox on Arch Linux on an old Atom-based netbook and on LMDE an old AMD 3200+. Neither have had issues, so it's not the case that Firefox is generically broken on all of Linux.
This is an odd statement, considering that many Firefox devs run Linux. I'm running Firefox on Linux right now, and it works great.
I guess the author of the article is hitting a specific bug. It isn't a general issue that affects all users of Firefox on Linux.