611 Defects, 71 Vulnerabilities Found In Firefox
Danny Begonia writes, "Some folks at Klocwork examined the large and complicated code base of the popular open source browser, Firefox. Overall, Firefox is a well written and high quality piece of software. Several builds were performed on the code, culminating in the final analysis of version 1.5.0.6. The analysis resulted in 611 defects and 71 potential security vulnerabilities. The Firefox team has been given the analysis results, and they will determine if or how they will deal with the issues." What are your thoughts — do Firefox and the open source community welcome this kind of analysis?
do Firefox and the open source community welcome this kind of analysis?
Obviously, yes. Otherwise, open source would be closed-source.
It seems mainly the problems were to do with memory leaks. Which having seen firefox eat 700mb of ram doesnt surprise me....As long as these probs get fixed i cant complain...Doning this kinda of analysis is much easier with the source code i imagine.
And nobody actually likes hearing the negative parts of them, but the wise will consider them and work on resolving the problems.
God I hope so. What on earth is the advantage of open source security if they don't get this kind of analysis?
TW
Seriously, any free testing is better than none. Especially when they point out the problems explicitly and hand them to you. As a developer, you're then given one last chance to fix your product -- if these even need to be fixed. I would expect things like the 134 memory leaks to be fixed and fixed fast. I've known Firefox to occasionally go on a memory splurge at my computer's expense and have expected this to be the problem. As far as some of these other problems that are mild security issues, they might not need to fix them at all.
Even the article admits that a lot of these "issues" are trivial to fix: Sounds like a two week job of an intern to me. Checking for null and handling it after memory allocation could probably be a cut and paste job. If they mention the line numbers and files, there's your fix.
Either way, this is the beauty of open source software, anyone can go in and do this. Now, if you found bugs in a proprietary program from some company and sent them a breakdown of problems, you'd get one of two responses. 1) No response and 2) A charge that you are reverse engineering their product and in violation of many anti-piracy laws. If the company still didn't address the issues and you published the bugs, then you're nothing but a software terrorist.
So let's kick back and watch open source at its best! No software is perfect, but it will be enjoyable to know that a process like this can occur -- with the end result being a better free product on my machine!
My work here is dung.
Why wouldn't people like the fact that an independant group audited the code?
At least with open source, you can do that. And, giving the report directly to the Mozilla people means that they know the issues are there and can address them.
Better than security through obscurity where only the one who found the exploit knows it's there.
Cheers
Lost at C:>. Found at C.
In an era of scandal secrets I welcome the opportunity to make an informed decision. In that vein does anyone have comparable numbers for Opera, IE or other popular browsers?
as a user, I value this kind of criticism - it's better out in the open where the devs are pressured to do something about it, than behind close doors where those of malicious intent can go about their nefarious business unhindered.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
Closed-source software companies are paranoid about this sort of thing. They are often openly hostile, to the point of suing anybody who does this sort of analysis.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
Right after they hired that Microsoft Security expert nevertheless!
What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
Why would they not welcome this kind of analysis? If they truly try to tout themselves as one of the more secure web browsers, especially compared to IE, then they should welcome criticism of the security of their products. I'm not sure whether this is a biased or non-biased analysis, but it is definitely worth looking into on the part of the community.
> What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
No, they're going to sweep this under the rug and disappear anyone else who audits their code. What the fuck do you think?
This will only make Firefox a stronger application on all of its builds, which means I feel confident using Firefox over its competitors. Remember everyone: FF > IE *flame suit on*
Found 700 bugs in a quick analysis? Wow, I want those people debugging my sourceforge projects too!!! Someone care to explain this FUD, I'm too lazy to RTFA.
Naturally the open source community appreciate this kind of analysis.
Even if the original coders don't particularly care - there will be others who do and the entire reason the code was opened is so people could find these vulnerabilities and fix them.
Seriously ... this basically is free work in finding bugs some user with less well-meant ambitions could have found and not reported.
Screw the FSM - Real geeks believe in the Invisible Pink Unicorn
Why wouldn't it be welcome? Pretending that problems don't exist is a horrible way to produce software (or anything, for that matter). I really can't even think of why such a question would be asked.
"What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?"
/question to this story.
I dont' understand how there can possibly be a "No we don't want that" argument. Me thinks someone tried to hard to add an interesting comment
--------========+++Dont Feed The Lab Techs+++========--------
Does Open Source encourage this kind of analysis and input? Absolutely. I'll take it two steps further. As of now, the Firefox team can:
1. Ignore the data.
2. Use the data to make a better product.
3. Look at the data, decide what is a true security issue/bug or not, and proceed on.
And, then there's also the option for the users:
1. Use Firefox as it is.
2. Make their own version.
The very idea of Open Source would, if there is a truly serious bug/security flaw that Firefox ignores, allow another group of people to fix the issue and release their own version - which could compete and even surplant the current Firefox version with the user base should people decide that's what they want.
So, without appearing rude, I would state that the question is a silly one. Yes, Open Source encourages this kind of analysis of all kinds. It just has a built in process that allows action to be taken - even if the primary code developer does not want to.
Of course, this is all just my opinion. I could be wrong.
52 Weeks, 52 Religions with John Hummel
Note that Klocwork, while definitely a good tool, does tend to produce a fair number of false positives, so it's not possible to try to compare an automated report of potential problems to a list of problems actually agreed to be a problem and actually fixed by an organization.
Of course they do. Closed source companies say "what's my profit motivation for fixing these, and how much is it going to cost me to do it, and what are the costs of not doing it". Open source projects (usually) don't operate under those restrictions, so there's little downside to having issues pointed out.
I don't see why the poster said "if" the Firefox team would use this report. They has been highly responsive in the past. I fully expect the Firefox team to analyize the results and fix the problems. Their bread and butter is to make it a stable and secure browser. To simply ignore these issues would be going against what they stand for.
That's sooo Osama bin Laden.
You have to know where the holes are to fix them. I can't see this being perceived as anything but good (improvements for Firefox now lie ahead) by reasonable members of the community. Sure, no one likes it when bugs are found in their code, but I would hope that most programmers genuinely want their code base to improve.
This is a great opportunity unless you are a PHB and/or marketing hack to use it as spin. I would guess the FireFox developers welcome the specifics and can then analyze and implement fixes to the problems found.
It does make one wonder about closed source applications where the independent eyes are not allowed. I, for one, would rather use an application that has been reviewed by independent sources. If browsers weren't free, I would pay for FireFox & Opera.
"Saying that Linux is inferior to Windows because more people use Windows is like saying that all restaurants are inferi
FTA:
Only someone with in-depth knowledge and background of the Firefox code could judge the danger of a particular security vulnerability; therefore, I have not included more detailed information of these security vulnerabilities that could lead to the spreading of unfounded rumours of potential exploits. However, for those interested, I've provided more details of the defects below.
Well here come the rumors. All software has issues, some more than others, but firefox is still less vulnerable than IE at present, and will most likley remain so. Moreover, its open source, so we can all find and fix if we have the skills to do so, and the Firefox Dev team can't hide from them.
I assume the IE codebase will be tested next for balance, and then Opera and Safari for interenst..
So how long till this gets blown out of all proportion?
Is that the closed-source people will jump all over the report and say "see how bad Firefox is?", when the reality is that a similar analysis of their browser would likely (I assume) turn up similar, if not worse, defect levels; of course, since the analysis can't be done, they get the opportunity to bad-mouth the open-source effort.
Hey, if it makes them fix the copy/paste bug, it's all good by me.
-----
...I recently wrote an article for Better Software (details here) showing the duplicated code and some other static analysis-type problems that PMD turned up in two fairly popular open source Java apps - Azureus and Columba. Both these programs are excellent open source apps, but both also had a number of places that could be improved.
This is kind of a Slashdot permathread, but anyhow, static code analysis is not a replacement for smart people also looking at the code. Rather, it augments folks' efforts and provides a safety net to catch little problems that can slip through. A duplicated code detector is especially useful because it can scan a massive codebase and help pick out chunks of code that can be refactored away. This reduces the lines of code, eliminates the possibility of duplicate bugs, and is great fun.
The Army reading list
Static analysis tools like the one used to produce this list tend to produce lots of false positives, because they can't make as many assumptions as a programmer who knows what's going on, and they can't follow most interactions between different modules. So the headline should be "611 *possible* defects, 71 *possible* vulnerabilities" found. More likely, a small handful of those will turn out to be real (but minor) bugs, and the rest will be bogus.
Obviously, yes. Otherwise, open source would be closed-source.
The numbers look large given that Firefox is supposed to be the superior browser, but can you imagine what those same numbers would look like for IE? Think Gates & Co. would care to give up the source code to do a head-to-head comparison? I'll bet the folks in Redmond are looking at these numbers and wondering just how to get IE's numbers that low.
GetOuttaMySpace - The Anti-Social Network
Is this going to be potential off by ones and buffer overflows or are their tools better than that?
by telling them 'Fix it yourselves, it's open source.' In the end, it is no different than closed-source to those that can't code.
Firefox just crashed while I was reading this article.
120 characters for a sig? That's bloody useless.
I wish they would have done a comparison with IE. Of course IE being closed-source they can't, but now all the IE fanboys are going to come out of the woodwork.
At first I thought "Great, another FUD piece overblowing what are probably trivial issues."
The I RTFA and saw that it was an honest report of errors given in a straightforward and clear manner.
And like other posters have mention, none of them sound that life-threatening.
I'm sure some Microsofties are going to be spinning this wicked for the next couple of months however.
My twitter
OK, I'll jump for your obvious trolling bait. But of course opensource solutions would welcome a reports such as this.
Its the closed source solutions providers that would cringe, pull hair, and writhe on the ground if it was ever published the results ran against their code.
(Oh, and they'd trundle out their FUD machines full force instead of actually fixing the identified issues)
Wherever you go... There you are. B.B.
What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
Not getting this kind of analysis isn't going to stop the bad guys from running them.
I did a lab last semester where two computers where set up, one running IE, one Running Firefox. I attempted to hack both of them using the BackTrack distro... a linux distrobution with a ton of tools and hacks to test vunerubilities. The conclusion? It took me less than 5min to hack the Box using IE through the browser. Took me 4 days for Firefox.
Going public with something like this when it is already in the hands of the developers seems somewhat self-serving. As far as I can tell there are no verified security holes. As a developer I would be annoyed.
... is that if there are ever bugs found, it's nothing to blame them on the guy next to you instead of yourself. 'Open Source' implies collective code ownership, after all.
Seriously, though, memory leaks and null-pointer references are pretty trivial. They can have this fixed by 2.0 easy.
sure, but why are they looking at 1.5.0.6 when 2.0 beta 2 is out? I switched to 2.0 beta a while ago because of annoying bugs in 1.5.x that were fixed in 2.0.
"Can't last more than 20 minutes on Myspace" bug?
Yeah, that's right. I just admitted to using Myspace for more than 20 minutes at a time.
Blessed be he who reads this post, Cursed be he who tells my boss.
I'm not sure why your post was moderated up at all. The fact that these problems were found and documented by a third party who had unfettered access to the source seems to support the idea that source availability actually does improve quality.
Ive been in the QA field since 97.... no matter the complexity of the application, there are countless bugs, defects, etc.... in fact development in most cases welcomes the more found, hence the more fixed. There is a book on Amazon called the Art of Software Testing (http://www.amazon.com/Art-Software-Testing-Second /dp/0471469122/sr=8-1/qid=1157645733/ref=pd_bbs_1/ 103-3570097-7021412?ie=UTF8&s=books), which states no matter how many defects are found, it's probably not even half of what could be found with plenty of people testing an application. With an application like a browser where millions of users become testers of sort, this is bound to happen. So this doesnt bother me, as hopefully one would think the vulnerabilities and major issues will be fixed....
In your post, you conflate software bugs with security vulnerabilities. These two things are not equivalent; at best, security vulnerabilities are a subset of software bugs.
my pet machine
i feel sorry for you; the future of IE: IE7 takes much longer to load than firefox.
i uninstalled ie7 and put ie6 back. ie6 had a good UI. ie7 sux.
Slashdot already had an article: Firefox Analyzed for Bugs by Software, where Coverity did automated scanning. That was welcomed by the OS community, as well as by Mozilla who partnered with Coverity to incorporate this.
"and that everything is layed out differently. Not too differently, but different enough that I want IE back." I think you mean laid. Have you not noticed then that you can click 'customize...' and move everything about? You probably don't like firefox because you've never really "used" firefox. It's a very decent browser, and I used to really like IE. Its your choice if you like IE or not, but bear in mind that microsoft deliberately make it nonstandard, and leverage their monopoly to get their own "standard" on the web, which is indeed a very evil and incorrect way to go about things. 52% compatibility? Forget it. Standards are an excellent thing and I cannot tolerate any person or company who decides to break them on purpose.
The biggest push I've heard given to corps over the years is not that OSS can be modified, enhanced, integrated, or reused, but that it can be inspected, reviewed, and fixed.
If there is anyone working in OSS who doesn't appreciate receiving such an analysis of potential bugs, then they shouldn't be programming anywhere. Whether for fun or profit, fixing the bugs and adding features is what the "job" is.
I do not fail; I succeed at finding out what does not work.
Well they certainly don't appreciate being reminded that they still don't support the disable-output-escaping feature of XSLT..
http://bugzilla.mozilla.org/show_bug.cgi?id=98168
..Jeff Keegan
seven syllables explain TiVo: kee gan dot org slash ti vo
I remember back when it was before 1.0, Firefox was quick and small. But it seems to be on the path of many pieces of bloatware. It just seems to get bigger and bigger, and slower and slower. Back then it was a tiny little app, now its almost 50MB expanded on my machine. Cripes. I think Firefox might be in need of a remake and return to its roots.
One of the top theoretical benefits of open source is the "Many eyes" method of bug spotting. And Klocwork provides an "electronic" eye. (I am imagining the Six Million Dollar Man sound effect here.)
Have you Meta Moderated t
700 defects sounds like a lot, but most were probably not done by manually examining the code.
:-)
More likely, it was a codebase scanner that checked for problems, such as memory leaks, double frees, stack issues, etc.
The real question is, was the scanner likewise scanned for problems?
I think this sort of stuff is great because the old practical advice of "getting an extra set of eyes" holds true, especially in technology. The tone of the report is professional instead of condesending, as so often I've seen on mailing lists when someone 'reviews' another's code. I imagine that this report will be well received by the Mozilla community at large. Even though the types of errors referenced in the report are common, it is still a great example of free software / open source philosophy working.
Comment removed based on user account deletion
I love criticism, it makes me stronger.
Should also make your software stronger
--
Now where did I put my brain...
-- I am the NRA, enough said...
No, those are not "irrelevant bugs". They're examples of very sloppy coding. Unfortunately, it is the type of coding that the Mozilla project is becoming known for.
And we're not in the "era of seemingly limitless virtual memory". It's not uncommon for typical desktop users to have no more than 1.5 GB, between RAM and swap. Often it's much less. With there being many reports of a single Firefox instance consuming over 700 MB after some fairly normal browsing sessions, a 1.5 GB limit is awfully close.
There is no reason for any code to be contributed to any open source project that doesn't perform such basic checks. If they Mozilla developers really want to avoid having to manage memory manually, then perhaps it is time for them to transition away from C++, to a language that offers automated memory management. Say, Haskell or OCaml.
There's lots of "this is a good thing, now they can fix these bugs" posts but no one seems to have looked deeper into the matter. These bugs and issues have been found using a piece of software (although it's not clear how much expertise is needed to use the tool) and found a long list. Why has this only recently been done on a high profile project? How many month or even years have these issues been around? Almost certainly a number of these issues can lead to potential exploits. Even if it's only a tiny percentage, if you've a list that can be generated easily and is of large enough size then a potential malware author could just go through them one by one until he spots a vulnerability he could take advantage of. At the moment Firefox still isn't worth hackers time because of the size and nature of the userbase but if it ever becomes mainstream having so many problems identified with automated tools will just make hacker's jobs easier. Use of these tools need to become more widespread in Opensource projects, at some point it WILL be worth malware author's time to find an exploit they can take advantage of.
What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
I would think the answer would be "yes, absolutely so."
Personally I've always thought people should make more extensive use of these kinds of automated code
analysis tools. When there are classes of problems that can be found using fairly mechanical means that
can be programmatically driven, it just makes sense to do so, IMO.
// TODO: Insert Cool Sig
"do Firefox and the open source community welcome this kind of analysis?" I think there should be people allowed to test the software for vulnerabilites and security risks because it lets the developers know about them sooner. In the end it should help this browser become more efficient and stable. I use Firefox on a regular basis. I love it. I also love the tabbed browsing as it makes my windows so much more managable. Before I had about 6 or 7 different browsers open before I used tabs. Keep up the great work firefox team!
It's great that the Firefox codebase has been scanned, but surely Firefox also depends on other open-source libraries? If these are not also scanned then the analysis is incomplete (although still much better than nothing).
Remember that all errors do not have the same severity or impact the user experience in the same way.
That could seems pretty low considering how many people have had their hands in it "cleaning it up".
I would be proud to be a part of that team. Let me just say GOOD JOB!
I thought I would put my $.01 cents into the pool here - having recently been through something like this.
Background: I am the author of some fairly unique software tools that allow you to communicate with industrial Programmable Logic Controllers. I consider the tools I write to be libraries with some example code showing how to use the library. It's all fairly simple stuff but one of my packages does a crapload of mallocs as it reads objects from the controller - basically it mallocs a data struct for every object, and then it also mallocs the data store for each object based on the data type (byte size) and how many items there are (3 dimensional array). In other words, a huge number of mallocs with no associated free statements.
So one day I get an email from a guy who was interested in using my software but wanted to know when I was going to remove all the memory leaks from my code. He was kind enough to include a valgrind report that showed a huge number of memory allocations that were never freed. It took me forever to explain to the guy that while I could "eliminate those memory leaks", it would also destroy the value of the library as it would in effect delete all the data read out of the controller.
Moral of the story: bug reports (including things like these code checkers and memory analysis programs like valgrind) are nice, but they need to be properly applied to be useful. Otherwise, these reports can be a significant distraction.
Ron Gage - Westland, MI
malloc() can return NULL if the allocation fails, but new never returns 0 (at least if it's complying to standard; C++ great weakness of letting you shoot yourself in the foot rears its head again). Instead, it throws a std::bad_alloc exception, which if uncaught will eventually bubble up and terminate your program noisily. (Unless you do something stupid like explicitly trapping the exception and then ignore it without handling the out of memory condition.)
This is nice because you never need to worry that a failed allocation won't cause an easily-noticed crash in a C++ program, and so can blithely new objects without checking every single one separately.
Yup, they will indeed be "spinning [it] wicked". But boy, wouldn't it be fun to see what would happen if the source for IE were opened up and a team of bug-finders who really liked their job spent a while ripping it apart?
IANAP but I think that 71 vulnerabilities in a FULL FEATURED web browser product is absolutely amazing. Just imagine if there was a chance to audit the source for IE? How many vulnerabilities do you think there would be, considering there are so many found without even LOOKING at the actual codebase?
It is pitch black. You are likely to be eaten by a grue.
It's called constructive criticism. And it's all about trying to make a great product even better.
This sig will self destruct in 5 seconds.
Of course this kind of analysis is welcomed. Open Source claims to write better and more secure code than closed operations as a result of community involvement and look-at-the-source-for-yourself accountability over the quality of the product. Therefore, this analysis directly supports the mission of open source. What I'd like to see is Microsoft submitting IE to the same public scruitny and maybe the senders of the 10 emails I received about this /. would shut the hell up.
One day the toilets of the world will rise up... And I'm going to nuke them.
...I can say that I am glad it is being run on something like Firefox.
I just wish there was something similar I could run on my own code (or that others could run on their code), anyone aware of something similar?
such as this should be considered good, as I'm sure the Firefox programmer community is generally doing. This is another ladder on the road to reaching critical mass of a user community. For years, I hated it when someone criticized my writing, but it finally dawned on me that most criticism is constructive and will be beneficial if it doesn't fall on deaf ears...
Firefox was never meant to be created in a vacuum, thus it should be taken as a compliment that this analysis was done.
I have this image in my head of an IE developer reading this story and thinking "Gee Slashdot, I guess writing a browser is pretty fucking hard, isn't it?"
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
"What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?"
No we prefer to be ignorant of the problems in software we write, we prefer to assume everything is perfect.
OF COURSE people prefer indepth analysis. I'm sure someone was like "damm it" when they got the report because they thought their code was flawproof but with the whole world as a consumer, people want to know what they can fix and make better, especially firefox who's core idea is create a browser that doesn't have problems like this.
Firefox is trying to build a better browser, the only way that can happen is if they get great and specific feedback ("the browser's too slow" doesn't help. "The browser's too slow when I go to this site" does.) Why would anyone not one an indepth analysis of a product you're currently working on? (the only time that sucks is if youre finishing it up for the final version and you will never work on it again and someone tells you about a year's worth of work left)
The more they find, the more they fix, the more secure Firefox becomes. That's the beauty of open source for you, folks. For IE you wouldn't even know about half the bugs and vulnerabilities (which doesn't mean hackers wouldn't know about them, though).
Touched by His noodly appendage.
Now, we see that there are many vulnerabilities in both IE and FireFox. Let's see what gets fixed faster.
The government can't save you.
They are no claiming that they have found security vulnerabilities, the say they have found potential security vulnerabilities. It is even possible that none of them are actually security vulnerabilities.
No one likes to have the project that they've put a lot of blood, sweat and tears into criticized, but this can only be for the best. That's what open source is all about, right? Anyone can look at the code, find bugs, and fix them (or tell the devs to fix them, in this case).
Besides, I thought they already paid Coverity to do them a similar service, and Coverity found some real show-stoppers. Why isn't anyone in the OSS world developing the kind of software that Coverity is making such a boatload of money from?
1.5.0.6. The analysis resulted in 611 defects and 71
You do realize that 611 + 71 is 682. And that 1506 + 682 = 2188. And that Feburary 1st, 1988 is in the year 1988, and that Kevin Karpenske who gave Firefox his domain has been (scroll down to see the post).
An *exposition* on *firefox*, well duh!
Have you read my journal today?
From what I've seen using Klocwork in the software development process, I would be surprised if more than a few turn out to actually be security issues. But, working through the analysis results should improve Firefox; so, it is a good thing.
I am looking at Bugzilla right now and there are some 351,680 bugs in there. Everyone panic.
members are seeing something, your seeing an ad
This is exactly what I've advocated for the 30+ years I've been an engineer. Spacecraft, mach-3 aircraft, probes, fundamental physics, all of it. We need code, we need open source code, we need independently verified code. This is a good thing.
Parent is wrong. Issues must be prioritized, and prioritization requires deciding if something is a minor issue or more important. If you have two issues where one is a single user's account being possible to destroy (not to gain access to the box, and not to destroy an arbitrary user's account, just a particular, specific user), and another bug where you can remotely perform arbitrary commands, as root, limited resources would be spent on the second one, first.
To claim that all security related bugs are equal is ignorant at best, and disingenuous (sp?) at worst.
Additionally, the particular requirements of an organization might make a particular bug minor. For example, if you can cause a printer to wait an extra second, once a day, before printing, you have a denial of service bug. Of course, this would be an insignificant DoS, as you can't effect anyone in any noticeable manner. But it's still a security issue, as it's still a DoS.
Mod parent down. S/he doesn't know what s/he's talking about.
..it might mean that in 682 possible places in the code, added/better documentation might be a good idea.
"So this doesnt bother me" ... who cares if this doesn't bother you? The memory leaks alone are the absolutely ridiculous. These type of problems are more the cause of rapid development with minimal QA (that's your field right?) and testing. If they used test units or XP (not windows) or whatever methodology the development may have been slower but the software would be of significantly higher quality.
...welcome our new independantly reviewed overlords.
(he said with karma to burn)
OSX bugs -> tar, feather, blonde^H^H^H^H^H^H mac user jokes
MS bugs -> tar, feather, detailed scatalogical analysis of the gates family tree, ballmer monkey boy video links
OSS bugs -> mature & measured discussion, navel gazing, produndities, kudos all around
ah.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Does the open source community that surrounds Firefox welcome this kind of analysis? I would have to say that's a RESOUNDING YES! As long as the analysis is truthful and reflects real problems that will improve the quality of Firefox I see no reason they wouldn't. Even pointing at minor issues will only help aid Firefox's improvement since it would give the developers a chance to see what people might really care about. And you can bet that if similar analysis was done of Internet Explorer that we'd find the same if not more defects and vulnerabilities. So this is NOT about Firefox vs. IE before anyone goes down that road.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Of course they welcome this. Just look at the results page for the Coverty scans and see how many defects have been fixed in major open source projects.
http://scan.coverity.com/
This is clearly M$ FUD. Don't fall for it. Firefox is open source. It doesn't crash or have bugs.
Rapid development happens all the time.... it puts QA in a crunch along with development. How about someone do a study on the other browsers, im sure the stats are the similar or higher. Of course more time helps, no one doubts that. At least this isnt EA Games with their retail releases are full of holes... this application is free you can choose not to use it.
611 Defects
71 Vulnerabilities
1 Browser...
The look on the face of a firefox fanboy: priceless.
I have to mention that the tool will report a number of warnings or so called errors that are noise in the output, as most tools have this problem.
Lets not forget, the company that is analyzing the code is a company who sells a product to do just that. It could be seen as a marketing ploy as well since the code is open source, they can do that.
This is not to say that there are not errors, but no tool finds all errors without finding non errors.
The answer is yes but only if "Some folks at Klocwork" have no ties to Microsoft. Duh.
Heard any good sigs lately?
Being an 18-year developer I realize that I will probably get pummeled for saying this, but has anyone on the Firefox team that may be reading this looked at AppSight for root-cause analysis with respect to problem resolution?
Memory allocations will almost never fail -- not even when the machine is actually out of memory (VM). Most modern operating systems use overcommit since many programs tend to allocate far more memory than they actually ever use; untouched pages need not have any backing. I should also note that Linux does allow you to turn this behavior off, but I'm not sure about other operating systems.
Anyway, in the unlikely event that a memory allocation should fail, I believe the behavior of C++ is to return null if exception support is turned off, and throw otherwise.
HAND.
the analysis isn't sponsored by Microsoft or somehow implies that M$ software is superior...
Who tagged Fud? 611 defects and 71 potential vulnerabilities sounds as less than what I was expecting of firefox, and this will help fixing them, so it is a very good thing.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
..."undocumented features"?
Talk without offending, listen without defending
This means that shortly, there will be 611 more bugfixes and 71 more potential security fixes!
I bet they're more busy trying to come up with a killer feature for it so marketting can hype it up and it won't matter how stable the competition is. Redmond learned a long time ago that they don't ever need to have a good product - just the most desirable image.
(Note that the main bug report linked is always marked invalid. That's not because anything has been done about the instability of Firefox; it's because people on the Firefox team don't want to, or don't know how to, fix the very, very serious bugs. Note also the links to magazine articles about Firefox instability, and the many links to user reports of problems.)
I'm posting this comment from Firefox version 1.5.0.6. It is using 22 percent of the CPU, even though all pages have been loaded, and there is no active content. That's 22% on the way to 70% or more, which will soon make it necessary to close all windows and tabs of Firefox and reboot Windows XP. (Firefox corrupts Windows XP SP2 with all patches applied, so that it is necessary to restart the OS. In Linux, it is necessary only to kill Firefox to get full control again.)
The CPU hogging bug in Firefox runs the fan in a laptop computer continuously, meaning that expensive hardware maintenance will be required more often for heavy Firefox users.
Firefox has extensions, but they often make Firefox unstable. The Firefox team thinks that it is entirely acceptable to market Firefox extensions, but when the extensions cause Firefox to be unstable, to excuse the instability by saying that it is caused by an extension.
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 problem appears to be that Firefox does not allocate enough resources. If you open several Firefox windows and several tabs in each window, and leave them open for several days, or suspend or hibernate your computer a few times, you will find that Firefox has started to hog the CPU.
It is interesting to note that, when the latest version of Firefox is used with the latest version of Thunderbird, they both have trouble with the CPU hogging bug. The each corrupt the other. Weird, and seemingly a good clue to the flaw that causes CPU hogging.
Apparently everyone on the Firefox team wants to add features or work on easy bugs. Apparently also, browser programmers are not necessarily heavy browser users. People who often do research on the internet, and open several Firefox windows and many tabs, and leave them open for several days, are certain or almost certain to cause Firefox to become unstable, however.
Mozilla Foundation Top 14 Excuses for Not Fixing Bugs
Top 14 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 4 years:
It's nice to see that the tests addressed the memory leaks and memory HOG status of Firefox.
I have noticed this especially when multimedia comes into play.
Having a browser for Windows that would tell the Internet to shut up when requested is key.
Hopefully they address this issue soon.
Internet Explorer analyze this!
FireFox Copy & Paste Bug: Fixed!!
What a fool believes, he sees, no wise man has the power to reason away.
"What are your thoughts do Firefox and the open source community welcome this kind of analysis?"
My thoughts are these ubiquitous, lazy, and insincere tag lines prove Slashdot editors long ago stopped giving a rat's ass about the topics which comprise the content of this site. Typically not a word denoting knowledge or interest in the subject is spent. An automated attendant can spit out 'what do you think', 'what are your thoughts', 'everyone discuss', etc.
Slashdot brought to you by Hallmark.
Still, Firefox is more secure that IE6... I wonder how many holes are in that piece of swiss cheese software?
Mozilla Foundation Top 15 Excuses for Not Fixing Bugs
Top 15 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 4 years:
I don't reckon 611 defects and 70 something vulnerabilities is that bad going.
This is the kind of number I'd expect on a small enterprise project with about 10 coders, lasting about 4 -6 months.
For something thats been tinkered with and expanded for near on three years (just as firefox, not even talking about the moz history) this aint bad at all.
Also you've got to take these "code analysis" things with a pinch of salt. Functions capable of returning null for example, only a small fraction of those would even be exposed to unvalidated input normally.
Sure these things should be sorted, but in my opinion it'll be a matter of weeks before all of these would be wiped out, with the caveat that when tfa says it gave the details to firefox, that it gave them more than a pretty management summary.
Wouldn't it be just typical for them to go, "Hey, we've found x defects in your code. Pay us and we'll tell you where they are."
Yes, as long as the analysis provides real, useful information.
I've seen cases before where security companies have discovered big piles of "vulnerabilities" in certain other high-profile open source products. The problem in those cases that made the "vulnerabilities" not entirely welcome "discoveries" was that really the security company had just run their automated code analysis product over the OSS codebase and dumped the results on the OSS community without looking over them first to weed out the sometimes large numbers of false positives. The security companies in those instances, presumably, were more interested in promoting their own security product ("look at all these vulnerabilities our product found!") than in truly enhancing the OSS product being examined.
Shit, that's depressing. Remember those halcyon days when we few, we happy few, we band of dorks touted our Linux desktops as rock-solid, with uptimes measured in months and sometimes years? When we mercilessly mocked Windows for its constant restarts, for reaching a level of baroque complexity so fearsome that all a user could do when something failed was to reboot the whole megillah?
So, nowadays, in the Linux desktop's most popular web browser, 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?
Restart the box.
Thanks, Firefox. Thanks a lot.
Laws do not persuade just because they threaten. --Seneca
Does anybody else think of Napoleon Dynamite when they read about defects? What if you're on a Gateway that's painted like a cow?
Oh. My. Pants. I saw that oo.org bug referred to in one of those posts that you link to.
Paraphrasing:
User: If you use the KDE save dialog, oo.org doesn't check before clobbering your files. Here's a simple three-line method to reproduce a bug that can cause users to lose data.
Developer: Works for me if I use the GTK or oo.org dialogs. *closes bug*
User: I said the *KDE* dialogs.
Developer: But oo.org uses its own dialogs. That's KDE's problem. *closes bug*
User: There's an option for using native dialogs! Right here! Also, no other KDE app has this problem. You're not using the filepicker correctly.
User 2: I can confirm this. Something's definitely up with the code interfacing with KDE's filepicker.
[five months pass]
Developer 2: Have you tried a newer version? Maybe it's fixed in the point release. Re-open if you're still having the problem. *closes bug*
I have to laugh, to keep from crying.
Laws do not persuade just because they threaten. --Seneca
Why wouldn't they want to know about potentially up to 71 vulnerabilities plus numerous other bits of code to cleanup?
Even when Opera is spoofing it's user agent string the text "Opera" is still in there and anyone making a reasonable effort to identify browsers will be able to count it accordingly. Opera's spoofing doesn't hide that it's Opera, it only acts a workaround for sites that only detect a common part of the IE/Mozilla UA string and wouldn't do anything if one of those aren't found.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Everytime I have to download another so called "patch" the version number remains the same(1.5.0.6)...something must be wrong!!!
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. ~Albert Einstein
What's the motivation to fix it in an Open Source environment? Altruistic tendencies?
What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
First we have the obligatory borg-like, "the community" reference. But the question should be re-phrased to "How many of you are so emotionally immature and insecure that you'll throw a tantrum because there might be something not uber-positive said about Firefox, Linux, Gnome, KDE...?"
P.S. who is making these thought decisions for "the community"?
It is reviewed by an independent qualified reviewer who has access to the build and source materials versus not-reviewed.
I worked for a very proprietary OS development group that submitted its source to two independent review and verification organizations. We received a very detailed summary of their findings. We fixed all the issues and resubmitted and they accepted the results. It is how the resultant OS got the highest Common Criteria Security Rating ever given to an OS. And it was done with a proprietary development model. And later versions will get the review again.
I bring this up only to point out that Proprietary and Independent Review aren't necessarily mutually exclusive, all you have to do is find a way to get that quality independent review.
Sometimes the reviewer wants publicity. Sometimes $$$.
No matter, it is the review and the quality of the reviewers that matters.
BAE's STOP is the OS, BTW.
like when your SO tells you, "overall I think you're a really great guy, but here, I've compiled a list of your 611 significant defects and 71 major character flaws."
I doubt many, if any, here on /. have ever contributed to Firefox code. There seems to be many critics of closed-source apps on here, but not actual Firefox developers.
Do Firefox and the open source community welcome this kind of analysis?
Yes, you silly wanker.
"Former Microsoft security strategist Window Snyder is joining Mozilla to lead the company's effort to protect its range of desktop applications from malicious hacker attacks."
4 7254
http://it.slashdot.org/article.pl?sid=06/09/06/21
# ~: no sigs today
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.
What a fool believes, he sees, no wise man has the power to reason away.
"The memory leaks alone are the absolutely ridiculous."
I've used Klocwork for analysis; in my experience, when K7 identifies a memory leak at location foo, it is correct less than 5% of the time. So, I would be quite surprised if even 10 of the 141 items flagged are actually memory leaks.
What a fool believes, he sees, no wise man has the power to reason away.
I fail to see the problem - If you are working on an open source project and someone steps in and tells you about problems you are not going to tell people to make like a tree.... or tell them to mind their own business - Au contraire you are going to welcome such a thorough analysis because it gives you the opportunity to better your software...
Some may argue that because of these numbers Firefox is riddled with holes and is no more secure than IE or any other browser. Here's the thing, though. It is Firefox's open-source nature than made this analysis possible. An independent party (could have been you or me) did this analysis. Try doing that with IE. Microsoft isn't going to let you.
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.
What a fool believes, he sees, no wise man has the power to reason away.
I think this type of analysis is great.
But I'm worried that open source projects arn't analysing their code themselves. Perhaps its better to have this stuff out sourced to professionals? But surley theres professionals that wouldn't mind do this in their free time to benifit a project, like it seems someone has done here.
Also, cant this process be automated. Like testing. Why is some type of automatic analysis done on every Release candidate.
Would it be that hard to do? Why dont they do it already? Are they afraid of the work it will create?
Along with this type of analysis, programs should be put through regular profiling so as to be able to spot potential bottle necks.
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
I'm running 2.0b2 right now. I wonder how many of them have already been fixed?
cp == b&
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
In this case the end result of not checking allocation results is, at worst, that you then try to access a null location, causing your app to GPF. Whoop dee doo.
You obviously have no experience with real-world software. A segfault caused by something as stupid as not checking the success of a memory allocation can be disasterous. Let's even just restrict ourselves to consumer/corporate-grade software. If that were to happen within a production web server, millions of dollars in sales could be lost. If that were to happen within a database system, the data loss could be very costly. If your browser were to crash while you were in the middle of performing an online banking transfer of several thousand dollars, it could lead to serious problems for you. And the worst part about such problems is that they're so easily detected!
And yes, dealing with a failed memory allocation can be complex. Software is often very complex. Professional developers know that, and successfully deal with it. Only an amateur would take your attitude of, "It's difficult to deal with, so I'll just ignore it if it happens, not caring what the result may be."
Many languages offering garbage collection do run into problems when all of the memory is consumed. Those that do happen to throw exceptions do so in a way that makes it very clear what the problem is, and why it occurred. Most of those that are suitable for production use don't just dump core. They alert a system operator to the lack of memory, and the operator can remedy the problem (if possible), and then allow for the execution to continue from where it left off.
That is not the case when a failed call to malloc() leads to a segfault, and you as the developer don't bother to check the return value. Unless you have a debugger, and a binary with debugging symbols and/or the source code of the application, you basically have no idea what happened. And if it were a failed allocation due to all the memory being consumed, it can be a most difficult problem to replicate. It might work fine on the developer's system with 1 GB of RAM and 2 GB of swap, but fail every time on your system with only 512 MB of RAM.
At least checking for the condition allows one to output an error message, even if it is handled by an immediate termination of the process. Your attitude of it being acceptable to not even check the return value is sickening. I hope that you are not allowed to perform any programming tasks, as you obviously lack the skills necessary to develop software in a safe, secure manner. Your lack of basic C programming technique is pathetic.
Would the community welcome bug reports of bugs not found by an automated tool? Say for example I found 50 bugs by hand and submitted the report to the team.
Firefox is a big, old, hairy C++ program, and for a big, old, hairy C++ program, that's not so bad.
While Firefox is important right now, the open source community really needs to start working on a successor in parallel. And, no, that doesn't mean another big, hairy C++ program.
That FF is buggy is no big revelation. The fact that the source is open to peer review (an OSS advantage) and scrutiny means that there is hope. However, having tried Firefox 2.0b I've noticed it still suffers from chronic memory leaks -- which even seem to permeate into the X server. With a desktop uptime that's measured in months, although KDE does save session state, running such resource corrupting desktop apps isn't an option. I certainly cannot recommend FF to anyone with a PC with less than 1GB RAM, Windows or otherwise. Why consider FF when there better alternatives, such as Opera (closed) and Konqueror (open).
Given the million or so /. accounts the number of Firefox developers can't possibly be more than an insignificant fraction, but we are nonetheless here.
That's actually a good idea. How about they add a Linux Firefox or KDE Firefox while they're at it? I'm sick of having to use GNOME Firefox because it's the only one available.
The Farewell Tour II
...And reading my name FROM THE EMAIL LISTED ABOVE is pure super techno fu. You must be some sort of elite hacker!
"because they can't make as many assumptions as a programmer who knows what's going on..." That's true. Of course, the next developer/maintainer who works on that code, or needs it to interface with it, or (heaven forbid!) re-uses it in another project won't know about all your assumptions, either. Whether you're engineering hardware or software, there's such as thing as trying to be too clever. It may seem easy today, but someday somebody will curse you while trying to find what has gone wrong. Think about how you feel when you find that long-gone developers not only made assumptions, but didn't describe exactly what they were, why they made them, and what's necessary for them to be valid. // and /* are your best allies when the new wears off the project!
But having done well over 25k installs of winxp through imaging and hand installs and scripting, and putting FF on about half, it's usually the windows install that's buggy, not the FF install.
FF has it's issues, but on the three machines in my house, FF uses 0% cpu. In fact, i have a single ie page open to Thotbot, and it's taking up the most cpu, FF is 12th, with 31 tabs open.
--
This sig is brok908sdn/#2
"The fact that these problems were found and documented by a third party who had unfettered access to the source seems to support the idea that source availability actually does improve quality."
Quality is not improved by finding problems, but by solving them.
I'm not sure if you're trolling or you're just in a bad mood, but I've noted that on all your three posts on this thread you mention the "Top 14 excuses". In the post I'm replying to, that list has no relation whatsoever with the rest of the post, it's just glued there like a sig. If I had mod points, I would have modded your post as "troll" (to any mod reading this, down a bit, not to -1).
Putting that list in all your posts is really counterproductive (if you want to make participate in the discussion I mean, if you're really trolling ignore what I've said).
As for your post, I agree with the others. Never seen the bug you're talking about (minimal CPU usage right now), but FF is a memory hog (hoards memory, but is tolerable). 1.5 also has a few annoying behaviours, like drag and drop crap (if anyone knows how to disable that, tell me) or middle click to paste (already disabled). In fact, I'm impressed that it turned out pretty stable, considering all I've been hearing about 1.5. I did keep 1.0 until a critical update forced me to upgrade, though.
(Using 1.5.0.6 on suse 10)
GPG 0x1B479C78
nt
Brain kills internet cells.
i think now its a time to look for another browser :)
http://www.secgeeks.com/
Well, the problem is that static ananlysis tools sometimes are having quite high level of false positives. Sometimes it might be about 80%, e.g. if a particular software uses it's own custom exception handling mechanism, etc. From what I saw in the report: most of those are 'possible dereferencing of NULL return' and such.
;-)
So, unless we can see a details of those 600+ bugs it's hard to tell if Firefox is buggy. I know for sure, that Coverity does analysis of Mozilla's software on a regular basis and the situation isn't that bad.
My point is that one shouldn't be in hurry of making conclusions
Take care, Cos
This article is just FUD but let's think it otherwise. If Firefox has 71 potential security vulnerabilities then how much do you think Internet Explorer has? I'd really love to see the real numbers for it. And I'd also like to know how these tests where performed to find a 'security holes'. I'd like to question all these tests since they are mostly bull. They can give glues where the software is or is not depending on who performs the tests. Microsoft will never open their source for somebody outsider to look at and analyze it. ;)
Ps. I personally think IE still has 666 holes in it's sources and at least one of these holes is a hole which won't never be fixed since it was made by goverment.
-Seeing the problem is ½ of solution-
"... I do wonder if there's something unique about your machine."
Numerous people have reported the CPU hogging bug, including some in this thread. I''ve tried several computers myself.
Interesting fact: If both Firefox and Thunderbird are running, Firefox sometimes causes Thunderbird to have the CPU bug. That fact seems to make it easy to find the bug. However no developer has ever read the bug reports, apparently.
The Firefox CPU hogging bug is also a very interesting social problem.
You didn't read the bug report, and there is plenty of evidence that none of the developers did, either.
The Firefox CPU hogging bug occurs only when several windows and several tabs are open for a long time, days sometimes. If Thunderbird is running, the problem is worse. If the user hibernates or suspends the computer, the problem is much worse.
Also, maybe there should be a list of excuses for the excuses.
And you reminded me of other excuses I had not yet documented.
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.
Interesting social science fact: Considering the responses, it is apparent that no one has read the bug reports thoroughly in the 4 years that the bug has been reported. It's easy to know early that the CPU hogging bug will be difficult to find, and apparently no one has read further.
Since no one commenting on this Slashdot story has read the bug reports, apparently, it is useful to repeat here that there is one fact that is important. The CPU hogging bug occurs only when several Firefox windows, each with several tabs, have been open for hours or days. Suspending or hibernating the computer (in Windows XP) make the problem happen sooner.
Interesting computer fact: The CPU hogging bug is communicable! Sometimes Firefox causes Thunderbird to hog the CPU! My guess is that fact makes it considerably easier to find the bug, or at least eliminate almost all of the code.
Another fact: Many people have guessed, based on the behavior, that the CPU hogging bug is caused by insufficient allocation of resources inside Firefox.
Mozilla Foundation Top 20 Excuses for Not Fixing Firefox Bugs
Here are the top 20 things Firefox and Mozilla developers say to those who report difficult bugs, collected over the last 4 years. See also the extensive information provided in this Slashdot comment, Firefox is the most unstable program in common use, and the links in the comment.
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.
What a fool believes, he sees, no wise man has the power to reason away.
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.
What a fool believes, he sees, no wise man has the power to reason away.
Well you are far more patient than I am. Once it started to thrash the swap file I would start closing programs.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
As a person who uses firefox regularly, I don't find it unstable. Sure, the latest release is a bit unstable, and had crashes like 3-4 times on me, but I find it completely usable. Frankly, it is difficult to have software that never crashes. In fact, in this fast pace of software development world, it is already acceptable by most that general software do have bugs and will crash.
I don't get the big deal with FF. Its an underpowered, WAAAAAY over hyped peice of software that really doesn't have much going for it other than it being open Source. And last time I checked, I didn't exactly feel like mucking through ugly web browser code. In my opinion Firefox is way hyped up and is not really 10% as good as people will try to Jedi mind Trick you into beleiving. Me, I switched to a great web browser long ago (hint hint: Opera), back when Mozilla.org abandoned Mozilla suite.
That being said, finding xxx amount of flaws and security problems in an ALREADY way over-hyped browser really doesn't do much in terms of winning me over. In short, I couldn't care less if Firefox has 3 x as much flaws and secirty problems! I also highly advise people not to buy the pre-packaged and manufactured firefox hype, and to try Opera. But no one ever listens.
over and out.
So what does the Firefox list tell us?
This could be fixed by using a memory allocation function that throws an exception on out-of-memory, rather than relying on the programmer to remember to check every call. If the programmer forgets to use a try/catch block to check for exceptions, the worst that happens is that the exception propagates upwards to a higher-level 'catch-all' routine.
Again, this shows that returning a special value such as null is not always the best thing to do. If it's likely that programmers will forget to check it (perhaps because null is only returned in error conditions, and doesn't occur during ordinary use), then an exception would be a better way to signal an error. It also lets you give more information about exactly what the error was; you can have different exceptions carrying different messages for different things that went wrong, but null is just null.
Hmm, but later on in TFA I see a comment from a Mozilla developer:
So it looks like the Mozilla folk have already thought about these problems and done the Right Thing.
-- Ed Avis ed@membled.com
hey, yeah there's good ol' microcrap lowering that common denominator for ya ...
What are we talking about again? Oh, right, a fucking web browser.
Actually, we are just talking about normal web browsers here. The rest of us, we do not perform sexual intercourse with our web browsers. We don't "fuck" our web browsers, as you claim to do. But many people do use their web browser to perform vital financial transactions online. A $1000 transfer may not seem like much in the grand scheme, but if a browser crash causes that transaction to fail, or otherwise become lost, the person performing the transfer will likey become quite irrate. Web browser stability is very essential.
Since you seem to be so sure of yourself and your programming abilities, I want you to post your full name, your current employer, your position with that employer, and a list of software products you have worked on. Do that for all of your past employers, and any projects you worked on at those places. I want to make sure that my firm never buys anything that you have worked on. From this discussion, you would appear to be an incompetent software developer who has little to no background writing secure, reliable systems. I don't want your software anywhere near my network.