The fact is, other browsers such as Opera are stable. No number of excuses will make Firefox stable; the bugs must be fixed. The media (see the link below) are starting to report Firefox instability; it makes sense to fix the bugs before Firefox gets a bad reputation.
Let's assume what you say is true. Firefox is horribly unstable. However, many people never see this instability. They have no idea what you're referring to. So saying "fix the instability problems" means nothing to us. You have to explain in detail what stability problems you're seeing. That's the point at which you get stuck. Yelling that problems should be solved isn't helping. Information that can be used to figure out what problems you're referring to is helpful.
You're the person with the information about the problem. You must convey that information to a person that is able to solve the problem. You might want to discuss the bug in the Firefox Bugs forum at MozillaZine so you can work together with other people who are unlucky enough to see the same problem. When you've gathered enough information so that you can state what the problem is clearly enough so others can see the problem, it can be fixed. Until then, it cannot. All the ranting in the world won't change that.
One thing you may not realize is that open bug tracking systems are just that -- open. Most of the people triaging bugs in Mozilla are not developers. With Mozilla's bug tracking system, all you need to do is attach two test cases to bug reports, and then you can get editbug permissions. Anyone with editbug permissions can close bugs. Just because you reported a bug and you had a discussion with someone that closed it, doesn't necessarily mean you had any contact at all with a developer, either a full-time Mozilla developer or even a volunteer developer. It could be a sixteen-year-old who has done a bit of QA work. If you see someone abusing Bugzilla privileges, please contact Gerv Markham about the problem.
For a browser to remain competitive these days, it needs to have loads of features and be fast. Supporting features takes memory. Memory is often traded for time to make the browser fast. You can try a no-frills browser such as Dillo or Links if you need every spare kB of RAM and want to have a browser open.
I have 1 GB of RAM, so the memory cache is 18 MB and the bfcache holds the last 8 pages I had open (pages take an average of 4 MB each). That adds up to 18 + 32 = 50 MB for cache out of 100 MB. The rest of the memory use is due to memory fragmentation, loaded plug-ins, XUL cache, etc.
My memory usage regularly goes over 200 MB, then back down to about 100 MB when I close all tabs. I tried Opera 9 when it first came out and its memory use went over 100 MB within a few hours. When memory use won't go below 200 MB without closing the browser, then you know you have a problem.
what's the first step one is to take when diagnosing any problem, in order for the developers to give you the time of day?
I don't think developers tell you to try the standard diagnostic. That's what end-users wrote in the MozillaZine Knowledge Base.
Developers will ask you if the problem happens with a new profile. If it doesn't, that means something different in the original profile triggers the problem. If someone can discover what that difference is, then the bug in Firefox can be found and fixed. It's not an excuse to avoid fixing a problem. It's troubleshooting what the problem is so it can be fixed.
15. # It's understandable that Firefox developers become defensive when users report so many problems.
Where on earth did I say that?
It should be:
15. There is no specific information about the bug in the bug report.
If you would stop with this general overall criticism and start reporting specific details of bugs so they can be reproduced and fixed, the problems you describe can be fixed. Until then, they cannot.
53% null pointer dereference (crashes)
17% memory leaks (generally in error conditions)
1% serious memory problems that could cause crashes
8% uninitialized variables (could causes crashes or other erratic behavior)
Given that there are hundreds of memory leak bug reports in Bugzilla, and the memory leaks found by this analysis occur generally only in error conditions and therefore are fairly rare, I don't think this report is going to have a huge impact on memory leaks. The good news is that I've been using Firefox 2 Beta 2, and it's leaking memory at such a slow rate that it would take weeks to eat up the memory on a computer that has just 256 MB of RAM.
If you're seeing a severe memory leak in Firefox 2 Beta 2, make sure it's reported in Bugzilla, with enough detail that others can reproduce the problem. Remember that it's normal for a browser's memory use to climb over 100 MB on the first day of use. Memory leaks generally don't become apparent until after several days of use. If you see Firefox 2 leak more than that, see earlier in this paragraph.
Making vulnerability reports public makes vulnerabilities easier to find and thus makes it more likely for them to be exploited. Security bugs should be reported privately, by checking the "This is a security problem that should be kept confidential until addressed (security policy)" checkbox when filing a bug in Mozilla software. And remember, if you're the first to report a security bug in Mozilla software (whether you check that box or not), you get a $500 Security Bug Bounty.
If someone makes a general overall criticism like "Firefox is the most unstable program in common use" I can imagine developers being offended or defensive. On the other hand, developers welcome clearly written bug reports that identify one specific problem like "Firefox crashes when visiting site xyz.com", because then they can address that issue by reproducing the problem. A detailed list of 611 defects and well-written bug reports are always welcomed!
Yes, there are isolated anecdotes of memory hogging in Opera. There are also isolated anecdotes of memory hogging in Firefox. If, on the other hand, you can reliably reproduce some type of memory problem in Firefox, please report the bug in Bugzilla or discuss it on MozillaZine, and feel free to draw our attention to it so the problem can be fixed. Until then, isolated anecdotes do not constitute a bug. The plural of anecdote is not data.
According to the Browser Speed Comparisons it looks like Firefox 2.0 is about as fast as Firefox 1.5 and Firefox 1.0. Maybe there was some gunk in your 1.5 profile that isn't in your 2.0 profile?
It doesn't sound like it's a bug. "HTML 4.01 is silent on what to do with them" means the behavior is undefined, so whatever Firefox does with CDATA is okay. Do you think Firefox's behavior is actually a bug according to published web standards? If so, file a bug report. Does Firefox not display some sites properly because of how it handles CDATA? If so, file a bug report and mention which specific sites are problematic. If not, then Firefox is adhering to standards and not breaking any sites, so there doesn't seem to be any problem.
Re:Firefox is the most unstable program in common
on
Marketing Mozilla
·
· Score: 1
The 1.5.0.4 version of Firefox was quite stable, if the Flashblock extension was installed. The 1.5.0.6 version is unstable again. The CPU-hogging bug is back!
Instead of posting on Slashdot about the problem, report a bug in Bugzilla and find the regression window. Then the bug can be fixed.
There are a fewbug reports about Firefox not interpreting CDATA correctly, but they are not confirmed. If you see a bug in Firefox, you should probably go directly to the bug database and make sure all the information about the problem is noted there if you want it to be fixed.
Aren't there already plenty of Firefox users who are using the latest Vista betas? If Firefox didn't work in Vista, there'd be lots of bug reports about it already.
Acid2 isn't about displaying a smiley. It's about getting developers of browsers to support the web standards that web developers have been wanting to use for years.
A developmental version of Gecko passes Acid2, and the plans are still for Firefox 3 (due out next year) to pass Acid2. Microsoft still has no plans to pass Acid2.
Slashdot Mirror
Let's assume what you say is true. Firefox is horribly unstable. However, many people never see this instability. They have no idea what you're referring to. So saying "fix the instability problems" means nothing to us. You have to explain in detail what stability problems you're seeing. That's the point at which you get stuck. Yelling that problems should be solved isn't helping. Information that can be used to figure out what problems you're referring to is helpful.
You're the person with the information about the problem. You must convey that information to a person that is able to solve the problem. You might want to discuss the bug in the Firefox Bugs forum at MozillaZine so you can work together with other people who are unlucky enough to see the same problem. When you've gathered enough information so that you can state what the problem is clearly enough so others can see the problem, it can be fixed. Until then, it cannot. All the ranting in the world won't change that.
One thing you may not realize is that open bug tracking systems are just that -- open. Most of the people triaging bugs in Mozilla are not developers. With Mozilla's bug tracking system, all you need to do is attach two test cases to bug reports, and then you can get editbug permissions. Anyone with editbug permissions can close bugs. Just because you reported a bug and you had a discussion with someone that closed it, doesn't necessarily mean you had any contact at all with a developer, either a full-time Mozilla developer or even a volunteer developer. It could be a sixteen-year-old who has done a bit of QA work. If you see someone abusing Bugzilla privileges, please contact Gerv Markham about the problem.
For a browser to remain competitive these days, it needs to have loads of features and be fast. Supporting features takes memory. Memory is often traded for time to make the browser fast. You can try a no-frills browser such as Dillo or Links if you need every spare kB of RAM and want to have a browser open.
I have 1 GB of RAM, so the memory cache is 18 MB and the bfcache holds the last 8 pages I had open (pages take an average of 4 MB each). That adds up to 18 + 32 = 50 MB for cache out of 100 MB. The rest of the memory use is due to memory fragmentation, loaded plug-ins, XUL cache, etc.
Extensions are also a common source of memory leaks. Report leaks in plug-ins and extensions to the developers of that software.
My memory usage regularly goes over 200 MB, then back down to about 100 MB when I close all tabs. I tried Opera 9 when it first came out and its memory use went over 100 MB within a few hours. When memory use won't go below 200 MB without closing the browser, then you know you have a problem.
Not that I know of. Last year someone got paid $2500 for five vulnerabilities he found. And remember there are 71 "potential" security vulnerabilities. I'm sure there are plenty of false positives in there.
I don't think developers tell you to try the standard diagnostic. That's what end-users wrote in the MozillaZine Knowledge Base.
Developers will ask you if the problem happens with a new profile. If it doesn't, that means something different in the original profile triggers the problem. If someone can discover what that difference is, then the bug in Firefox can be found and fixed. It's not an excuse to avoid fixing a problem. It's troubleshooting what the problem is so it can be fixed.
Where on earth did I say that?
It should be:
15. There is no specific information about the bug in the bug report.
If you would stop with this general overall criticism and start reporting specific details of bugs so they can be reproduced and fixed, the problems you describe can be fixed. Until then, they cannot.
The breakdown is more like this:
53% null pointer dereference (crashes)
17% memory leaks (generally in error conditions)
1% serious memory problems that could cause crashes
8% uninitialized variables (could causes crashes or other erratic behavior)
Given that there are hundreds of memory leak bug reports in Bugzilla, and the memory leaks found by this analysis occur generally only in error conditions and therefore are fairly rare, I don't think this report is going to have a huge impact on memory leaks. The good news is that I've been using Firefox 2 Beta 2, and it's leaking memory at such a slow rate that it would take weeks to eat up the memory on a computer that has just 256 MB of RAM.
If you're seeing a severe memory leak in Firefox 2 Beta 2, make sure it's reported in Bugzilla, with enough detail that others can reproduce the problem. Remember that it's normal for a browser's memory use to climb over 100 MB on the first day of use. Memory leaks generally don't become apparent until after several days of use. If you see Firefox 2 leak more than that, see earlier in this paragraph.FireFox Copy & Paste Bug: Fixed!!
Making vulnerability reports public makes vulnerabilities easier to find and thus makes it more likely for them to be exploited. Security bugs should be reported privately, by checking the "This is a security problem that should be kept confidential until addressed (security policy)" checkbox when filing a bug in Mozilla software. And remember, if you're the first to report a security bug in Mozilla software (whether you check that box or not), you get a $500 Security Bug Bounty.
If someone makes a general overall criticism like "Firefox is the most unstable program in common use" I can imagine developers being offended or defensive. On the other hand, developers welcome clearly written bug reports that identify one specific problem like "Firefox crashes when visiting site xyz.com", because then they can address that issue by reproducing the problem. A detailed list of 611 defects and well-written bug reports are always welcomed!
Yes, there are isolated anecdotes of memory hogging in Opera. There are also isolated anecdotes of memory hogging in Firefox. If, on the other hand, you can reliably reproduce some type of memory problem in Firefox, please report the bug in Bugzilla or discuss it on MozillaZine, and feel free to draw our attention to it so the problem can be fixed. Until then, isolated anecdotes do not constitute a bug. The plural of anecdote is not data.
I see plenty of posts about Opera 9.0 hogging memory too.
According to the Browser Speed Comparisons it looks like Firefox 2.0 is about as fast as Firefox 1.5 and Firefox 1.0. Maybe there was some gunk in your 1.5 profile that isn't in your 2.0 profile?
It doesn't sound like it's a bug. "HTML 4.01 is silent on what to do with them" means the behavior is undefined, so whatever Firefox does with CDATA is okay. Do you think Firefox's behavior is actually a bug according to published web standards? If so, file a bug report. Does Firefox not display some sites properly because of how it handles CDATA? If so, file a bug report and mention which specific sites are problematic. If not, then Firefox is adhering to standards and not breaking any sites, so there doesn't seem to be any problem.
There are a few bug reports about Firefox not interpreting CDATA correctly, but they are not confirmed. If you see a bug in Firefox, you should probably go directly to the bug database and make sure all the information about the problem is noted there if you want it to be fixed.
Aren't there already plenty of Firefox users who are using the latest Vista betas? If Firefox didn't work in Vista, there'd be lots of bug reports about it already.
Acid2 isn't about displaying a smiley. It's about getting developers of browsers to support the web standards that web developers have been wanting to use for years.
A developmental version of Gecko passes Acid2, and the plans are still for Firefox 3 (due out next year) to pass Acid2. Microsoft still has no plans to pass Acid2.