Re:Firefox has very serious problems.
on
Firefox Secrets
·
· Score: 1
SeaMonkey is much more configurable. Give it a try.
Re:Mozilla browser (SeaMonkey) has the SAME proble
on
Firefox Secrets
·
· Score: 2, Informative
You're almost certainly trolling, but I'll reply to some points anyway.
Some bugs are very difficult to characterize. Those require a developer to be a true scientist. However, Firefox developers apparently look for bugs that are easy to fix. Bugs such as this one, which is now more than 2 1/2 years old, are ignored. I think everybody believes it's many bugs that add up to cause the problems users see, not just one single bug. That makes it much harder to track down the individual issues.
It's insulting and ignorant to claim that developers ignore the hard bugs.
No developer has asked me for more information, but they have marked the CPU and memory hogging bug reports as invalid. There's probably a reason (if only that your bug report is the same as hundreds of others and equally useless). Care to post bug #s?
Every month I make part of my living as a writer, and have done so for more than 18 years. I did a very clear test using both Windows XP and Linux, and found the same problem. People sometimes write novels for bug reports, with great detail about the useless tests they conducted and irrelevant statistics they measured during the test. That doesn't make them good or valid.
You said, "Many bugs that are filed aren't important to 99.99% of the userbase."
That's a new excuse! I've added it as number nine in my list. That excuse does NOT apply here. The CPU and memory hogging bug is being discussed publicly in long articles you apparently didn't read. You didn't specify what bugs you were talking about. I don't think people would say huge leaks are unimportant, but many people file pointless bugs or bugs on things that could just as well be considered features. I was responding in a generic way to your generic "excuse".
You didn't read the articles in Information Week, and you apparently have no theory about why there are such SERIOUS problems in Mozilla browser and Firefox. I read the articles (they didn't say anything interesting). I read multiple forums where people talk about Firefox leaks. I know what issues people complain about. But users just go on and on about the same symptoms, never providing specific testcases that reproduce issues. Multiple people often decide that they're experiencing the same bug when they clearly are not. They perceive changes between releases that don't exist (e.g. claiming certain changes occurred between 1.0.6 and 1.0.7 that, if you look at the code, could not have). Addressing complaints on issues like these tends to be a hopeless task.
If you could just create one page that, when reloaded repeatedly demonstrated increasing memory usage, that would be incredibly helpful. A testcase in which you load a page in a tab, close the tab, and repeat to demonstrate increasing memory usage would also probably be useful. But nobody does.
You claim it can take days to reproduce the bug, and it happens through normal use. Well, steps to reproduce such as "surf for a day" for you might be checking forums for new trolls about why Firefox is bad. For someone else, it might be contributing to Wikipedia articles. For another user it might be using LXR to trace through some code. Even if a developer DOES experience the problem, how does he/she track it down? Tools such as valgrind make the browser run 100x slower while being debugged - can you possibly surf for a week like that? Other tools give you too much data to have the slightest hope of wading through it all to find the problems. It's a hard problem. People DO work on it, and memory leaks are constantly being fixed. But there are probably a lot of them, and they all take time.
The article talks about setting a specific memory cache size... if you read the source code, you'd know that Gecko is smart enough to already pick cache sizes based on the amount of RAM you have, AND it picks small values - if I remember correctly, SMALLER than the ones suggested in the article. The author of the article probably saw the tweak mentioned on some forum where nobody bothers to conduct scientific comparisons.
Re:Firefox has very serious problems.
on
Firefox Secrets
·
· Score: 1
What are you talking about? Does ctrl+tab not do anything on mac? Did you file a bug? Firefox or SeaMonkey? If Firefox developers said no, I can't help you. If you're talking about SeaMonkey, I can ask if there's a reason for whatever behavior (or lack thereof) is bothering you.
Re:"... occasional crash due to mem leaks..."
on
Firefox Secrets
·
· Score: 1
Care to enlighten me as to how memory leaks cause crashes?
Re:Firefox has very serious problems.
on
Firefox Secrets
·
· Score: 1
I love Firefox, but this is a ridiculous comment. Firefox will regularly consume 200-400mb on my machine even when I'm viewing pages that have at most 1 or 2 small 20-30k images. I'm not denying that there are leaks - I personally experience them and after a week my browser is often up in the 200-400MB range too. I'm saying that people file bugs about the browser takeing 300MB when it's not leaks, and comment about legitimate memory usage in bugs that are really about leaks, making it harder to figure out when real leaks are happening due to the "bugspam" we have to wade through to find useful info.
Plugins run in-process for many reasons. As a result, if the plugin performs an illegal operation (accesses memory out of bounds, divides by 0, etc), the browser gets killed when the OS kills the process. There are some protections in place to handle certain plugin failures, but it's impossible to prevent them all - since the plugin runs in-process, it could overwrite any part of the browser's memory and cause SeaMonkey to crash later in some other, unrelated part of the code. Would you rather not be able to use plugins and not have in-browser video, flash, or Java? Those are viewed as "killer" (as in, super-important) features by many people.
The software I write (cash register software) would be considered unreleasable if it crashed. Is a cash register nearly as complex as a modern internet suite? Most cash registers I've seen appear to run a command-line application or a simple interface written in Java or VB. High performance isn't an issue for them. Extensibilitiy isn't either - do you support plugins that anybody can write and integrate seamlessly?
I notice that Mozilla and Firefox developers talk about crashes in what seems to me to be an easy-going fashion. Nobody likes crashes, but we acknowledge they exist, and provide workarounds when we have them.
I'm beginning to wonder if you're just an anti-Mozilla troll, based on your recent posts.
Re:Firefox has very serious problems.
on
Firefox Secrets
·
· Score: 1
One more comment about bad bugs - many users think >0% CPU usage is excessive, and >20MB memory usage is excessive. How do you think pages get rendered? The CPU does some computation. Of course the CPU usage will spike while a page is loading. If you're viewing a page with a lot of pictures, where do you think the bitmaps are stored? A single 1024x768x32-bit image takes 3MB. If you load a page with 100 large images, of course the browser will need >300MB.
Re:Firefox has very serious problems.
on
Firefox Secrets
·
· Score: 5, Informative
I am a SeaMonkey developer. I fix SeaMonkey bugs, a small number of Gecko bugs, and a very small number of Firefox bugs.
Mozilla developers refuse to consider bugs that bug reporters cannot characterize completely. You have to understand that we get a HUGE number of useless bugs filed - bugs that say "Huge memory leak", and claim that it's easy to reproduce, or bugs that claim large amounts of CPU usage and again claim it's easy to reproduce. Just because it's easy to reproduce for YOU doesn't mean it's easy to reproduce for US. Additionally, many users use extensions, which basically invalidate their bug reports since we can't possibly debug under the effects of the many changes extensions make, ESPECIALLY if we don't know what extensions and versions of extensions you're using. A report that doesn't completely explain a problem is not necessarily bad if the user is helpful enough and provides good answers when we ask them questions, but too many people file bugs and then can't give us the answers we need.
See this Slashdot comment: Leadership problem? See this list of excuses: 1) Maybe this bug is fixed in the nightly version. MANY bugs are fixed every day, and it's very aggravating to spend hours of our time tracking down a problem only to find that it was fixed already. It takes the user 5 minutes to try a nightly. I think asking the user to get a nightly build is reasonable.
2) Yes, this bug exists, but it isn't important. Many bugs that are filed aren't important to 99.99% of the userbase.
3) No one has posted a TalkBack report. (If they read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too.) I would hope that isn't the normal case. I haven't catualy heard of situations that crash talkback anyway (other than maybe flaky hardware).
4) If you would just give us more information, we would fix this bug. If we don't see it, and you don't give us more info about it, how do we fix it? Read your mind? Other magic?
5) This bug report is a composite of other bugs, so this bug report is invalid. (The other bugs aren't specified.) Ask what bugs.
6) You are using Firefox in a way that would crash any software. Example?
7) I don't like the way you worded your report. If you file a bug that says, "You guys are idiots, you write shitty software that leaks 500MB", you get what you deserve. If you use awful grammar and difficult-to-read style, well, why do you expect us to put hours into fixing a bug when you don't bother to spend 5 minutes properly reporting it?
If you can't write in English (or a language one of the developers understands), it can be very difficult to figure out what the problem is.
8) You should run a debugger and find what causes this problem yourself. That's not a nice answer, but sometimes developers don't have the time to fix the problem. You're free to pay somebody, but if you want it done for free, you might have to do it yourself.
You have to remember that people have their own lives - SeaMonkey comes after school for me (the 1.0 beta release would have happened a few hours earlier if not for a final exam I had that day, which I had to study for over the weekend). When I'm fixing bugs, it's at the expense of playing games, seeing a movie, studying, or doing something else fun. Fortunately for you, I happen to find it interesting enough to do it anyway, fixing not only bugs that interest me personally but bugs that other people want fixed. The least you could do is say thank you, rather than bitch that I and people like me are not doing enough free labor for you. For developers who are paid, many have specific tasks assigned to them, and need to complete those tasks before they work on other things.
I'm not saying there aren't problems that need to be acknowledged, but many common complaints are ignorant and/or unreasonable.
You can do a much better raytracer with canvas than without it - previously you'd have needed a large table or many divs to display the image, but with canvas the output can actually be drawn properly.
So this is the 5307th. What's the big deal? Zalewski's "mangleme" crashers were interesting enough to be on slashdot because he presented an interesting tool to do testing, but this is just one crash among thousands.
Any of the dozens of known crash bugs in the public bugzilla database can be used to DoS Firefox. One more way to crash is hardly newsworthy. If it only affects pre-1.0.7 versions, it's been patched anyway!
CPU Game Math Performance
* 9.6 billion dot product operations per second 9.6GFLOPS*60=576GFLOPS. That's not even remotely close to 1TFLOPS, let alone 60 TFLOPS. You're off by 2 orders of magnitude.
Ummm... are you aware of what exactly was changed for Firefox 1.0.3 that broke extensions? Someone did find ways to do basically what you were saying, and it was all addressed. Big architectural changes were made to address the problem, making Mozilla significantly more secure.
http://bcheck.scanit.be/bcheck/page.php?name=STATS 2004 In 2004, there was only ONE WEEK during which there were no known remote code execution exploits for fully-patched MSIE. There were 30 days for Firefox if you don't count Mac OS (which would be fair if we're only interested in browsers for Windows users).
I personally strongly prefer SeaMonkey... there are a bunch of reasons. I've used it (well, the Mozilla suite) for a few years and am more used to it, and I see more eye-to-eye with other SeaMonkey developers.
Firefox is somewhat annoying to use, because lots of little things are just different (for example, if you type something in the URL bar, SeaMonkey will open it in a new tab if you hit ctrl+enter, while Firefox uses alt+enter; Firefox's download manager has annoying default behaviors; having a separate search bar instead of just searching from the URL bar means both your URL bar is smaller and you can see less of what you type when you search for something; find-as-you-type has a weird dialog in Firefox; many other things). If you haven't used SeaMonkey before, though, some of these won't be a problem for you. Another annoyance is that Firefox changes a lot between each release - the fact that the options window was redone basically from scratch between FF1.0 and FF1.5b means that a lot of things are in different places now. A nice thing about the suite is that since it's integrated, you don't have to set all your preferences twice (in the browser, and in the email client).
As a developer, I don't like some of the practices used in Firefox... for large patches, their philosophy seems more like "include the patch and let users (people who use the nightly builds) find bugs" whereas in SeaMonkey we do more up-front code review. When porting Firefox patches to SeaMonkey, I've had them be rejected because the code quality I copied wasn't good enough, so they had to be cleaned up. I really don't like the way the "lead Firefox developer" (Ben Goodger - in quotes because that title is really unfair to the other Firefox devs) seems to do his big patches... in the cases I've looked at, he checked in patches that either were entirely broken (when he rewrote the options dialog, it didn't work at all and was mostly invisible (see-through, I'm not kidding)), or full of bugs that a few minutes of testing would find (the info bar that alerts you to blocked popups, blocked extensions, missing plugins, etc. had a lot of bugs I came across when I ported it to SeaMonkey).
A lot of Firefox's popularity probably just comes from the fact that it's new and therefore "cool" or interesting, whereas the suite looks similar to Netscape 4. It seems that the new name "SeaMonkey" is actually generating a little interest though, which is kind of cool.
If you're into testing lots of extensions, Firefox makes it easier (specifically, uninstalling extensions in SeaMonkey is hard), but the thing about SeaMonkey is that I don't need extensions with it, so it isn't really a problem. I have one extension (FlashBlock) that I've used for years and never needed to uninstall... and I used autoscroll until recently (autoscroll will be integrated in SeaMonkey 1.0 Beta, so I don't need the extension any more).
Anyone who tells you Firefox is faster is probably confused or buying into hype. Every recent test I've seen has SeaMonkey starting up faster (even without QuickLaunch, which makes it launch almost instantaneously - a feature Firefox doesn't have), and they use the exact same rendering engine, so pageload speeds are the same.
I'm not sure how they compare in memory use, but in my experience, the cache and webpages themselves tend to use significantly more RAM than the interface itself, so I wouldn't expect much difference. People like to say SeaMonkey is "bloated", but if you also use an email program, however, SeaMonkey is going to be a LOT smaller than Firefox+Thunderbird, because it shares a lot of data, while FF+TB duplicate a lot. A quick test showed Firefox alone was ~21MB at launch, and SeaMonkey ~22MB. Opening the mail client for SeaMonkey only bumped it up to ~28MB though, while Thunderbird is going to eat another 20MB or so for itself.
letting them choose the download folder, so they're not prompted where to save every download Edit->Preferences, Navigator->Downloads, "Automatically download files to the specified folder".
Unfortunately, because the Mozilla Foundation doesn't seem to have the resources to help out with things like setting up branch tinderboxes (and producing builds), many SeaMonkey people have been busy taking care of those tasks, necessary to actually get a release out the door. Tasks like setting up tinderboxes can be especially difficult when the people familiar with tinderbox setup give your project low priority and don't have time to give you the info you need. Asa still hasn't bothered to simply say "yes" or "no" to giving SeaMonkey people access to the FTP stage server so we can publish the contrib builds we do produce. We've been asking for almost 3 weeks.
It's not a good use of our time to backport code improvements (unless it's easy/the files were identical or nearly identical to start with). This is especially the case when we do sync files (e.g. tabbox.xml), and then Firefox people go change their version only (and don't even bother to tell us). It can be frustrating.
It's not so much Firefox, as it is the Mozilla codebase upon which Firefox is built.
Just so people don't think that means the upcoming SeaMonkey release will be using shoddy code, I'd like to point out that code review for firefox-only code is significantly less thorough than review for suite-only code. In many cases, large Firefox patches have been checked in with no code review at all! On multiple occasions when porting features from Firefox to SeaMonkey, the patches were initially rejected due to code quality, and had to be fixed up.
Releases are built with Microsoft Visual C++ 6, because there are concerns that the license of newer versions would not allow the builds to be distributed.
If you look at the source code that reads that preference, it really looks like that fix is entirely bogus.
1259/** 1260 * CacheMemoryAvailable 1261 * 1262 * If the browser.cache.memory.capacity preference is positive, we use that 1263 * value for the amount of memory available for the cache. 1264 * 1265 * If browser.cache.memory.capacity is zero, the memory cache is disabled. 1266 * 1267 * If browser.cache.memory.capacity is negative or not present, we use a 1268 * formula that grows less than linearly with the amount of system memory. 1269 * 1270 * RAM Cache 1271 * --- ----- 1272 * 32 Mb 2 Mb 1273 * 64 Mb 4 Mb 1274 * 128 Mb 8 Mb 1275 * 256 Mb 14 Mb 1276 * 512 Mb 22 Mb 1277 * 1024 Mb 32 Mb 1278 * 2048 Mb 44 Mb 1279 * 4096 Mb 58 Mb 1280 * 1281 * The equation for this is (for cache size C and memory size K (kbytes)): 1282 * x = log2(K) - 14 1283 * C = x^2 - x + 2 1284 */
You're setting it to a higher value than what it would be have if you had 4GB of RAM.
It's not a "design flaw" - actually implementing fast back properly is very difficult. There are a lot of sublteties you aren't seeing - for example, the page could have some JS scripts running, and you need to preserve their state. If you resized a window and then went back, you need to make sure that the page gets the resize event. It's not as simple as it sounds.
Slashdot Mirror
SeaMonkey is much more configurable. Give it a try.
You're almost certainly trolling, but I'll reply to some points anyway.
Some bugs are very difficult to characterize. Those require a developer to be a true scientist. However, Firefox developers apparently look for bugs that are easy to fix. Bugs such as this one, which is now more than 2 1/2 years old, are ignored.
I think everybody believes it's many bugs that add up to cause the problems users see, not just one single bug. That makes it much harder to track down the individual issues.
It's insulting and ignorant to claim that developers ignore the hard bugs.
No developer has asked me for more information, but they have marked the CPU and memory hogging bug reports as invalid.
There's probably a reason (if only that your bug report is the same as hundreds of others and equally useless). Care to post bug #s?
Every month I make part of my living as a writer, and have done so for more than 18 years. I did a very clear test using both Windows XP and Linux, and found the same problem.
People sometimes write novels for bug reports, with great detail about the useless tests they conducted and irrelevant statistics they measured during the test. That doesn't make them good or valid.
You said, "Many bugs that are filed aren't important to 99.99% of the userbase."
That's a new excuse! I've added it as number nine in my list. That excuse does NOT apply here. The CPU and memory hogging bug is being discussed publicly in long articles you apparently didn't read.
You didn't specify what bugs you were talking about. I don't think people would say huge leaks are unimportant, but many people file pointless bugs or bugs on things that could just as well be considered features. I was responding in a generic way to your generic "excuse".
You didn't read the articles in Information Week, and you apparently have no theory about why there are such SERIOUS problems in Mozilla browser and Firefox.
I read the articles (they didn't say anything interesting). I read multiple forums where people talk about Firefox leaks. I know what issues people complain about. But users just go on and on about the same symptoms, never providing specific testcases that reproduce issues. Multiple people often decide that they're experiencing the same bug when they clearly are not. They perceive changes between releases that don't exist (e.g. claiming certain changes occurred between 1.0.6 and 1.0.7 that, if you look at the code, could not have). Addressing complaints on issues like these tends to be a hopeless task.
If you could just create one page that, when reloaded repeatedly demonstrated increasing memory usage, that would be incredibly helpful. A testcase in which you load a page in a tab, close the tab, and repeat to demonstrate increasing memory usage would also probably be useful. But nobody does.
You claim it can take days to reproduce the bug, and it happens through normal use. Well, steps to reproduce such as "surf for a day" for you might be checking forums for new trolls about why Firefox is bad. For someone else, it might be contributing to Wikipedia articles. For another user it might be using LXR to trace through some code. Even if a developer DOES experience the problem, how does he/she track it down? Tools such as valgrind make the browser run 100x slower while being debugged - can you possibly surf for a week like that? Other tools give you too much data to have the slightest hope of wading through it all to find the problems. It's a hard problem. People DO work on it, and memory leaks are constantly being fixed. But there are probably a lot of them, and they all take time.
The article talks about setting a specific memory cache size... if you read the source code, you'd know that Gecko is smart enough to already pick cache sizes based on the amount of RAM you have, AND it picks small values - if I remember correctly, SMALLER than the ones suggested in the article. The author of the article probably saw the tweak mentioned on some forum where nobody bothers to conduct scientific comparisons.
What are you talking about? Does ctrl+tab not do anything on mac? Did you file a bug? Firefox or SeaMonkey? If Firefox developers said no, I can't help you. If you're talking about SeaMonkey, I can ask if there's a reason for whatever behavior (or lack thereof) is bothering you.
Care to enlighten me as to how memory leaks cause crashes?
I love Firefox, but this is a ridiculous comment. Firefox will regularly consume 200-400mb on my machine even when I'm viewing pages that have at most 1 or 2 small 20-30k images.
I'm not denying that there are leaks - I personally experience them and after a week my browser is often up in the 200-400MB range too. I'm saying that people file bugs about the browser takeing 300MB when it's not leaks, and comment about legitimate memory usage in bugs that are really about leaks, making it harder to figure out when real leaks are happening due to the "bugspam" we have to wade through to find useful info.
Plugins run in-process for many reasons. As a result, if the plugin performs an illegal operation (accesses memory out of bounds, divides by 0, etc), the browser gets killed when the OS kills the process. There are some protections in place to handle certain plugin failures, but it's impossible to prevent them all - since the plugin runs in-process, it could overwrite any part of the browser's memory and cause SeaMonkey to crash later in some other, unrelated part of the code. Would you rather not be able to use plugins and not have in-browser video, flash, or Java? Those are viewed as "killer" (as in, super-important) features by many people.
The software I write (cash register software) would be considered unreleasable if it crashed.
Is a cash register nearly as complex as a modern internet suite? Most cash registers I've seen appear to run a command-line application or a simple interface written in Java or VB. High performance isn't an issue for them. Extensibilitiy isn't either - do you support plugins that anybody can write and integrate seamlessly?
I notice that Mozilla and Firefox developers talk about crashes in what seems to me to be an easy-going fashion.
Nobody likes crashes, but we acknowledge they exist, and provide workarounds when we have them.
I'm beginning to wonder if you're just an anti-Mozilla troll, based on your recent posts.
One more comment about bad bugs - many users think >0% CPU usage is excessive, and >20MB memory usage is excessive. How do you think pages get rendered? The CPU does some computation. Of course the CPU usage will spike while a page is loading. If you're viewing a page with a lot of pictures, where do you think the bitmaps are stored? A single 1024x768x32-bit image takes 3MB. If you load a page with 100 large images, of course the browser will need >300MB.
I am a SeaMonkey developer. I fix SeaMonkey bugs, a small number of Gecko bugs, and a very small number of Firefox bugs.
Mozilla developers refuse to consider bugs that bug reporters cannot characterize completely.
You have to understand that we get a HUGE number of useless bugs filed - bugs that say "Huge memory leak", and claim that it's easy to reproduce, or bugs that claim large amounts of CPU usage and again claim it's easy to reproduce. Just because it's easy to reproduce for YOU doesn't mean it's easy to reproduce for US. Additionally, many users use extensions, which basically invalidate their bug reports since we can't possibly debug under the effects of the many changes extensions make, ESPECIALLY if we don't know what extensions and versions of extensions you're using. A report that doesn't completely explain a problem is not necessarily bad if the user is helpful enough and provides good answers when we ask them questions, but too many people file bugs and then can't give us the answers we need.
See this Slashdot comment: Leadership problem? See this list of excuses:
1) Maybe this bug is fixed in the nightly version.
MANY bugs are fixed every day, and it's very aggravating to spend hours of our time tracking down a problem only to find that it was fixed already. It takes the user 5 minutes to try a nightly. I think asking the user to get a nightly build is reasonable.
2) Yes, this bug exists, but it isn't important.
Many bugs that are filed aren't important to 99.99% of the userbase.
3) No one has posted a TalkBack report. (If they read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too.)
I would hope that isn't the normal case. I haven't catualy heard of situations that crash talkback anyway (other than maybe flaky hardware).
4) If you would just give us more information, we would fix this bug.
If we don't see it, and you don't give us more info about it, how do we fix it? Read your mind? Other magic?
5) This bug report is a composite of other bugs, so this bug report is invalid. (The other bugs aren't specified.)
Ask what bugs.
6) You are using Firefox in a way that would crash any software.
Example?
7) I don't like the way you worded your report.
If you file a bug that says, "You guys are idiots, you write shitty software that leaks 500MB", you get what you deserve. If you use awful grammar and difficult-to-read style, well, why do you expect us to put hours into fixing a bug when you don't bother to spend 5 minutes properly reporting it?
If you can't write in English (or a language one of the developers understands), it can be very difficult to figure out what the problem is.
8) You should run a debugger and find what causes this problem yourself.
That's not a nice answer, but sometimes developers don't have the time to fix the problem. You're free to pay somebody, but if you want it done for free, you might have to do it yourself.
You have to remember that people have their own lives - SeaMonkey comes after school for me (the 1.0 beta release would have happened a few hours earlier if not for a final exam I had that day, which I had to study for over the weekend). When I'm fixing bugs, it's at the expense of playing games, seeing a movie, studying, or doing something else fun. Fortunately for you, I happen to find it interesting enough to do it anyway, fixing not only bugs that interest me personally but bugs that other people want fixed. The least you could do is say thank you, rather than bitch that I and people like me are not doing enough free labor for you. For developers who are paid, many have specific tasks assigned to them, and need to complete those tasks before they work on other things.
I'm not saying there aren't problems that need to be acknowledged, but many common complaints are ignorant and/or unreasonable.
You can do a much better raytracer with canvas than without it - previously you'd have needed a large table or many divs to display the image, but with canvas the output can actually be drawn properly.
I stand by my statement.
r mat=advanced&short_desc_type=allwordssubstr&short_ desc=crash&resolution=DUPLICATE&resolution=---&chf ieldto=Now
r mat=advanced&keywords_type=allwords&keywords=crash &resolution=DUPLICATE&resolution=---&chfieldto=Now
"crash" in bug summary:
https://bugzilla.mozilla.org/buglist.cgi?query_fo
"crash" keyword (5306 open or duplicate reports):
https://bugzilla.mozilla.org/buglist.cgi?query_fo
So this is the 5307th. What's the big deal? Zalewski's "mangleme" crashers were interesting enough to be on slashdot because he presented an interesting tool to do testing, but this is just one crash among thousands.
Any of the dozens of known crash bugs in the public bugzilla database can be used to DoS Firefox. One more way to crash is hardly newsworthy. If it only affects pre-1.0.7 versions, it's been patched anyway!
CPU Game Math Performance
* 9.6 billion dot product operations per second
9.6GFLOPS*60=576GFLOPS. That's not even remotely close to 1TFLOPS, let alone 60 TFLOPS. You're off by 2 orders of magnitude.
Microsoft has distributed infected versions of software in Korean too.
Ummm... are you aware of what exactly was changed for Firefox 1.0.3 that broke extensions? Someone did find ways to do basically what you were saying, and it was all addressed. Big architectural changes were made to address the problem, making Mozilla significantly more secure.
http://bcheck.scanit.be/bcheck/page.php?name=STATS 2004
Your questions are addressed on pages 3 and 4.
http://bcheck.scanit.be/bcheck/page.php?name=STATS 2004
In 2004, there was only ONE WEEK during which there were no known remote code execution exploits for fully-patched MSIE. There were 30 days for Firefox if you don't count Mac OS (which would be fair if we're only interested in browsers for Windows users).
I personally strongly prefer SeaMonkey... there are a bunch of reasons. I've used it (well, the Mozilla suite) for a few years and am more used to it, and I see more eye-to-eye with other SeaMonkey developers.
Firefox is somewhat annoying to use, because lots of little things are just different (for example, if you type something in the URL bar, SeaMonkey will open it in a new tab if you hit ctrl+enter, while Firefox uses alt+enter; Firefox's download manager has annoying default behaviors; having a separate search bar instead of just searching from the URL bar means both your URL bar is smaller and you can see less of what you type when you search for something; find-as-you-type has a weird dialog in Firefox; many other things). If you haven't used SeaMonkey before, though, some of these won't be a problem for you. Another annoyance is that Firefox changes a lot between each release - the fact that the options window was redone basically from scratch between FF1.0 and FF1.5b means that a lot of things are in different places now. A nice thing about the suite is that since it's integrated, you don't have to set all your preferences twice (in the browser, and in the email client).
As a developer, I don't like some of the practices used in Firefox... for large patches, their philosophy seems more like "include the patch and let users (people who use the nightly builds) find bugs" whereas in SeaMonkey we do more up-front code review. When porting Firefox patches to SeaMonkey, I've had them be rejected because the code quality I copied wasn't good enough, so they had to be cleaned up. I really don't like the way the "lead Firefox developer" (Ben Goodger - in quotes because that title is really unfair to the other Firefox devs) seems to do his big patches... in the cases I've looked at, he checked in patches that either were entirely broken (when he rewrote the options dialog, it didn't work at all and was mostly invisible (see-through, I'm not kidding)), or full of bugs that a few minutes of testing would find (the info bar that alerts you to blocked popups, blocked extensions, missing plugins, etc. had a lot of bugs I came across when I ported it to SeaMonkey).
A lot of Firefox's popularity probably just comes from the fact that it's new and therefore "cool" or interesting, whereas the suite looks similar to Netscape 4. It seems that the new name "SeaMonkey" is actually generating a little interest though, which is kind of cool.
If you're into testing lots of extensions, Firefox makes it easier (specifically, uninstalling extensions in SeaMonkey is hard), but the thing about SeaMonkey is that I don't need extensions with it, so it isn't really a problem. I have one extension (FlashBlock) that I've used for years and never needed to uninstall... and I used autoscroll until recently (autoscroll will be integrated in SeaMonkey 1.0 Beta, so I don't need the extension any more).
Anyone who tells you Firefox is faster is probably confused or buying into hype. Every recent test I've seen has SeaMonkey starting up faster (even without QuickLaunch, which makes it launch almost instantaneously - a feature Firefox doesn't have), and they use the exact same rendering engine, so pageload speeds are the same.
I'm not sure how they compare in memory use, but in my experience, the cache and webpages themselves tend to use significantly more RAM than the interface itself, so I wouldn't expect much difference. People like to say SeaMonkey is "bloated", but if you also use an email program, however, SeaMonkey is going to be a LOT smaller than Firefox+Thunderbird, because it shares a lot of data, while FF+TB duplicate a lot. A quick test showed Firefox alone was ~21MB at launch, and SeaMonkey ~22MB. Opening the mail client for SeaMonkey only bumped it up to ~28MB though, while Thunderbird is going to eat another 20MB or so for itself.
letting them choose the download folder, so they're not prompted where to save every download
Edit->Preferences, Navigator->Downloads, "Automatically download files to the specified folder".
Unfortunately, because the Mozilla Foundation doesn't seem to have the resources to help out with things like setting up branch tinderboxes (and producing builds), many SeaMonkey people have been busy taking care of those tasks, necessary to actually get a release out the door. Tasks like setting up tinderboxes can be especially difficult when the people familiar with tinderbox setup give your project low priority and don't have time to give you the info you need. Asa still hasn't bothered to simply say "yes" or "no" to giving SeaMonkey people access to the FTP stage server so we can publish the contrib builds we do produce. We've been asking for almost 3 weeks.
It's not a good use of our time to backport code improvements (unless it's easy/the files were identical or nearly identical to start with). This is especially the case when we do sync files (e.g. tabbox.xml), and then Firefox people go change their version only (and don't even bother to tell us). It can be frustrating.
It's not so much Firefox, as it is the Mozilla codebase upon which Firefox is built.
Just so people don't think that means the upcoming SeaMonkey release will be using shoddy code, I'd like to point out that code review for firefox-only code is significantly less thorough than review for suite-only code. In many cases, large Firefox patches have been checked in with no code review at all! On multiple occasions when porting features from Firefox to SeaMonkey, the patches were initially rejected due to code quality, and had to be fixed up.
If you followed the discussions on IRC, you'd see that people are working on the bug.
mconnor: we're in security firedrill mode. probably not meeting on beta2 today.
They're all busy dealing with this issue... everything else is on hold.
Releases are built with Microsoft Visual C++ 6, because there are concerns that the license of newer versions would not allow the builds to be distributed.
Everybody knew Acid2 complaince wouldn't make it in Gecko 1.8. It's not like passing some random test is super-important as long as normal pages render properly.
If you look at the source code that reads that preference, it really looks like that fix is entirely bogus.
/**
1259
1260 * CacheMemoryAvailable
1261 *
1262 * If the browser.cache.memory.capacity preference is positive, we use that
1263 * value for the amount of memory available for the cache.
1264 *
1265 * If browser.cache.memory.capacity is zero, the memory cache is disabled.
1266 *
1267 * If browser.cache.memory.capacity is negative or not present, we use a
1268 * formula that grows less than linearly with the amount of system memory.
1269 *
1270 * RAM Cache
1271 * --- -----
1272 * 32 Mb 2 Mb
1273 * 64 Mb 4 Mb
1274 * 128 Mb 8 Mb
1275 * 256 Mb 14 Mb
1276 * 512 Mb 22 Mb
1277 * 1024 Mb 32 Mb
1278 * 2048 Mb 44 Mb
1279 * 4096 Mb 58 Mb
1280 *
1281 * The equation for this is (for cache size C and memory size K (kbytes)):
1282 * x = log2(K) - 14
1283 * C = x^2 - x + 2
1284 */
You're setting it to a higher value than what it would be have if you had 4GB of RAM.
It's not a "design flaw" - actually implementing fast back properly is very difficult. There are a lot of sublteties you aren't seeing - for example, the page could have some JS scripts running, and you need to preserve their state. If you resized a window and then went back, you need to make sure that the page gets the resize event. It's not as simple as it sounds.