You honestly don't think that a browser with over 300M users and ~30% marketshare isn't being hit by black hats looking for exploits? Really? Personally, I'd say that's an overly-optimistic point of view.
The memory bloat bugs that I see get dismissed are generic complaint bugs with little or no information with how to reproduce it. Here's a hint: "Just browse around for awhile and you'll see the problem" is not helpful. You don't have to look beyond this very thread to see plenty of people who can't reproduce those problems with their regular browsing habits. If you can't give useful steps to reproduce or a testcase that clearly shows the problem, how can you expect it get any traction with anyone? On the other hand, look at even a recent bug like Browser not responsive while loading HTML5 spec to see how much attention a bug can get when useful information is provided with it.
And I don't recall anyone saying anything about it being a feature, not a bug, other than Ben's oft-cited and ancient blog post that's not even relevant anymore given how much has changed with Gecko's memory management since then.
As a matter of policy, all fixes land on mozilla-central (Minefield) prior to landing on the 1.9.1 branch (Shiretoko). It's done that way to avoid landing performance and stability regressions on a branch moving toward release.
That sounds pretty bad. Have you considered filing a bug with a testcase? That would be infinitely more helpful than complaining on Slashdot. Believe it or not, there are people at Mozilla who do care about such things.
Wow, what a helpful answer. Care to provide specific sites that are broken rather than random anecdotal remarks? It's kind of hard to fix something if it can't be easily reproduced.
Firefox 3.0.x is only open to security and stability updates at this point, so it's highly unlikely that you'll see any increases in its Acid3 score at this point (short of the test itself changing somehow). The recently-released 3.1b2 scores 93/100 (also unlikely to change before it goes final). There are also patches posted in Mozilla's Bugzilla tracker (currently either awaiting review or needing more work to be done) that when landed will get their score up to 97/100, probably for Firefox 3.2. The only part of Acid3 that they haven't yet addressed is SVG Fonts, and it seems that little has been done in that area so far.
Personally, I don't mind their approach of trying to make sure that the issues raised by Acid3 are fixed in a timely manner, but not rushing fixes before they're ready just to have a bigger number. And besides, as long as IE8 still only scores 12/100 (or 21/100 if you're willing to wait long enough), it's kind of a moot point. It seems to me that what's relevant isn't who hits 100/100 first, but who hits it last.
One thing that changed substantially during the Firefox 3 development cycle was that Mozilla finally created a useful testing architecture to spot and avoid regressions much better than before. Also, they've switched to Mercurial for post-3.0 development to allow for better development on concurrent branches while staying off the trunk. As a result, they're aiming to keep the trunk in a constant release-ready state specifically to allow for faster turnaround time for 3.x releases.
I can't speak to the specifics of your warranty, but more often than not, big box retailer extended warranties are actually handled through an outside firm, not by the retailer itself. For that reason, I'd imagine that if you've got an 800 number to call on your warranty form, you'll be OK for the future.
I'm just curious, have you tried playing with a recently nightly build? Many developers actually do use Macs and have spent a lot of time working on improving things for Fx3. If you haven't already done so, try it out and see for yourself. If nightlies aren't your thing, Firefox 3 Beta 1 should be officially released some time within the next few days. I think you'll be pleasantly surprised.
Did you even RTFA? The point is that Mozilla2 (the backend for ALL Gecko 2.0-based browsers, including Firefox 4.0) is going to be cleaning things up so much that making a lightweight mobile browser is a realistic option. The wins that will be good in the mobile space are going to be going in to the main codebase first and foremost. The only change is that with the code lighter, a mobile browser is something which can be made well and supported well.
Slashdot Mirror
Particularly funny since there's a pretty nice-size contingent of ex-Firefox developers on the Chrome team.
He died a bit over a year ago.
You honestly don't think that a browser with over 300M users and ~30% marketshare isn't being hit by black hats looking for exploits? Really? Personally, I'd say that's an overly-optimistic point of view.
See bug 475606 and associated dependencies.
The memory bloat bugs that I see get dismissed are generic complaint bugs with little or no information with how to reproduce it. Here's a hint: "Just browse around for awhile and you'll see the problem" is not helpful. You don't have to look beyond this very thread to see plenty of people who can't reproduce those problems with their regular browsing habits. If you can't give useful steps to reproduce or a testcase that clearly shows the problem, how can you expect it get any traction with anyone? On the other hand, look at even a recent bug like Browser not responsive while loading HTML5 spec to see how much attention a bug can get when useful information is provided with it.
And I don't recall anyone saying anything about it being a feature, not a bug, other than Ben's oft-cited and ancient blog post that's not even relevant anymore given how much has changed with Gecko's memory management since then.
Define "heavy"
As a matter of policy, all fixes land on mozilla-central (Minefield) prior to landing on the 1.9.1 branch (Shiretoko). It's done that way to avoid landing performance and stability regressions on a branch moving toward release.
They released 3.0.7 yesterday with security fixes as well, presumably the same ones that 3.1 got where applicable.
Firefox 3.1 (3.5) uses NanoJIT from Tamarin for Tracemonkey. They scrapped the other plans (Actionmonkey) a long time ago.
That sounds pretty bad. Have you considered filing a bug with a testcase? That would be infinitely more helpful than complaining on Slashdot. Believe it or not, there are people at Mozilla who do care about such things.
Wow, what a helpful answer. Care to provide specific sites that are broken rather than random anecdotal remarks? It's kind of hard to fix something if it can't be easily reproduced.
Please don't use Filterset.G. There are far better options out there.
http://adblockplus.org/en/faq_project#filterset.g
And those governments would certainly never think of abusing such authority by creating backdoors for themselves. No, of course not...
Firefox 3.0.x is only open to security and stability updates at this point, so it's highly unlikely that you'll see any increases in its Acid3 score at this point (short of the test itself changing somehow). The recently-released 3.1b2 scores 93/100 (also unlikely to change before it goes final). There are also patches posted in Mozilla's Bugzilla tracker (currently either awaiting review or needing more work to be done) that when landed will get their score up to 97/100, probably for Firefox 3.2. The only part of Acid3 that they haven't yet addressed is SVG Fonts, and it seems that little has been done in that area so far.
Personally, I don't mind their approach of trying to make sure that the issues raised by Acid3 are fixed in a timely manner, but not rushing fixes before they're ready just to have a bigger number. And besides, as long as IE8 still only scores 12/100 (or 21/100 if you're willing to wait long enough), it's kind of a moot point. It seems to me that what's relevant isn't who hits 100/100 first, but who hits it last.
You know that Opera is working on similar functionality for their next major version too, right?
One thing that changed substantially during the Firefox 3 development cycle was that Mozilla finally created a useful testing architecture to spot and avoid regressions much better than before. Also, they've switched to Mercurial for post-3.0 development to allow for better development on concurrent branches while staying off the trunk. As a result, they're aiming to keep the trunk in a constant release-ready state specifically to allow for faster turnaround time for 3.x releases.
I can't speak to the specifics of your warranty, but more often than not, big box retailer extended warranties are actually handled through an outside firm, not by the retailer itself. For that reason, I'd imagine that if you've got an 800 number to call on your warranty form, you'll be OK for the future.
I find your lack of Star Wars knowledge disturbing.
Wrong. Windows XP has always included IE6 from the initial gold release to the forthcoming SP3.
Mozilla will be going back to the x.y.z numbering system from 3.0 on.
For more information, see this blog post from Asa Dotzler.
I think that overhaul is something being looked into for the Gecko 2.0 (Fx4) timeframe.
I'm just curious, have you tried playing with a recently nightly build? Many developers actually do use Macs and have spent a lot of time working on improving things for Fx3. If you haven't already done so, try it out and see for yourself. If nightlies aren't your thing, Firefox 3 Beta 1 should be officially released some time within the next few days. I think you'll be pleasantly surprised.
And no, Firefox today != IE2003, not even close.
Check out their financial FAQ as well. They specifically talk about how they'll be increasing money spent on grants in the next year.
Did you even RTFA? The point is that Mozilla2 (the backend for ALL Gecko 2.0-based browsers, including Firefox 4.0) is going to be cleaning things up so much that making a lightweight mobile browser is a realistic option. The wins that will be good in the mobile space are going to be going in to the main codebase first and foremost. The only change is that with the code lighter, a mobile browser is something which can be made well and supported well.