Slashdot Mirror

That's why creating a new profile is the most recommended fix for Firefox problems: "With a new profile the application will run without any extensions, themes, or customized settings that may be causing problems." Updating your plugins and drivers can help also. For more information, you can look at the MozillaZine Knowledge Base or the new official Firefox support site.

That's why creating a new profile is the most recommended fix for Firefox problems: "With a new profile the application will run without any extensions, themes, or customized settings that may be causing problems." Updating your plugins and drivers can help also. For more information, you can look at the MozillaZine Knowledge Base or the new official Firefox support site.

Microsoft ignores standards, goes off in their own direction.

Actually... It's the web standards community that gave Microsoft the green light to go off in their own direction (and hoping other browsers will do the same).

IE8's new scheme and those supporting it are being met with an equal level of criticism.

Yeah, if you're a web designer, it's best you read the stuff that's flying around out there. It's an pretty big and important change being proposed for web development standards.

Cheers,
Fozzy

Okay, but what happens when somebody at Mozilla think it's such a dumb idea that he doesn't want it implemented in future versions of Firefox?

Microsoft claims that the X-UA-Compatible flag is necessary on standards-compatible content to avoid breaking IE-specific content. I call BS.

For years, Microsoft has been telling everyone to put version-specific IE hacks in conditional comments, in case IE's behavior improves in future versions. Now that they are finally fixing IE, they spring this X-UA-Compatible "solution" on us, punishing those who have been producing standards-compliant content and rewarding the zombies who have been writing IE-specific code. If your site is standards-compliant, you have to do the extra work to tag it as such, and keep that crufty tag around for the foreseeable future!

If you sat down today and wrote a new standards-compliant browser, it would work just fine with almost all the content and web applications out there. Apple did this recently with Safari. Microsoft claims to have done this with IE 8. Safari didn't need any X-UA-Compatible flag. Why should IE 8 need one?

The only reason IE 8 would need the X-UA-Compatible flag is simply because it is IE 8. If their new browser identified itself as, say, "Microsoft Trident VI" instead, things would just work. Microsoft could still call it "Internet Explorer 8" for marketing purposes, but web developers would know that "MS Trident VI" means IE 8, just as "WebKit 4xx" means Safari 2 (or similar browsers) and Gecko means Firefox (or similar browsers).

Dear Microsoft, here's a sane solution for you:

1. Ditch the X-UA-Compatible flag; it's a stupid idea.
2. Continue supporting HTML conditional comments as you have been doing.
3. Fix the layout engine and the CSS parser at the same time, so that any existing IE-specific CSS hacks become irrelevant.
4. Add support for CSS conditional comments, to give web designers an escape route. Let's face it, CSS hacks are a reality, so we might as well have a tool to do it cleanly.
5. Send this as the User-Agent string: Mozilla/5.0 (compatible; Microsoft Trident VI; Windows NT x.y; ...; Microsoft Internet Explorer 8.0; ...). Any server-side code doing browser sniffing, not seeing the "MSIE" string, should send a standards-compliant response. User-Agent strings have never really been logical anyway -- IE started this mess years ago by sending the "Mozilla" string, and Opera continued the trend by optionally sending the "MSIE" string -- so additional games in this area wouldn't do any more harm to the Web.
6. In JScript, navigator.appName should return 'Microsoft Trident', and navigator.userAgent should return the string above. Client-side scripts doing explicit browser sniffing, not seeing the "MSIE" string, would suppress their legacy IE hacks.
7. In JScript, document.all should evaluate to false (although expressions involving document.all can still behave as in older versions of IE). This approach worked for Mozilla, and it will work for Microsoft too.

As you see, it is possible to fix IE in a backward compatible way without introducing a X-UA-Compatible flag. The chances of Microsoft taking these steps is almost nil, since it places IE 8 on an even playing field with other standards-compliant browsers. That's why they are proposing X-UA-Compatible -- they can claim to support web standards while knowing that web developers will find it easier to muddle along than to use their stupid flag.

I've blogged about why I don't think we'll follow this path in Firefox.

http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html
http://weblogs.mozillazine.org/roc/archives/2008/01/slipping_the_ba.html

One interesting thing is that as far as I can tell, this will become a crushing burden on IE development.

I've blogged about why I don't think we'll follow this path in Firefox.

http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html
http://weblogs.mozillazine.org/roc/archives/2008/01/slipping_the_ba.html

One interesting thing is that as far as I can tell, this will become a crushing burden on IE development.

All I can say is that any time I try doing the same thing in Firefox and another browser, Firefox really does use less memory than the other browser. I cannot prove to you that I personally do not see a problem, and you obviously don't believe me. On the other hand, I do believe you see a problem. My suggestion is to discuss the problem in the MozillaZine forums so you can get a resolution. Perhaps you can point out a specific problem in Firefox or fix a problem that is happening on your computer. Surely if there's an obvious problem, you'll find many people who can see the same problem you do, and it will be trivial to reproduce. Then, you can report the bug and get it fixed. It'll be as simple as that if Firefox really does use three times IE's memory opening any particular eight tabs. Why not go there and point out the problem already?

I just launched FireFox on the same machine. It has one tab open showing a blank page. This takes 47MB of RAM (not too excessive) and 3% of my CPU. Apparently it takes FireFox as much CPU to be inactive showing a blank page as it takes Safari to show 33 tabs and have me typing in one of them. Oh, and I have no plugins loaded in either browser.

Memory usage is terrible, I find the UI sluggish, render times are far from ideal and the whole thing just feels... not what it was.

I keep seeing people make statements like this, but when I ask for steps to reproduce any problem, no one can seem to come up with any. Can you show me how I could see memory usage significantly worse than other browsers, user interface responsiveness significantly worse than other browsers, render times significantly worse than other browsers, or any other problem in Firefox?

If you're having problems with Firefox, you may want to try creating a new profile or other suggestions from the MozillaZine Knowledge Base. I see the suggestions help users all the time in the MozillaZine forums.

Memory usage is terrible, I find the UI sluggish, render times are far from ideal and the whole thing just feels... not what it was.

I keep seeing people make statements like this, but when I ask for steps to reproduce any problem, no one can seem to come up with any. Can you show me how I could see memory usage significantly worse than other browsers, user interface responsiveness significantly worse than other browsers, render times significantly worse than other browsers, or any other problem in Firefox?

If you're having problems with Firefox, you may want to try creating a new profile or other suggestions from the MozillaZine Knowledge Base. I see the suggestions help users all the time in the MozillaZine forums.

Memory usage is terrible, I find the UI sluggish, render times are far from ideal and the whole thing just feels... not what it was.

I keep seeing people make statements like this, but when I ask for steps to reproduce any problem, no one can seem to come up with any. Can you show me how I could see memory usage significantly worse than other browsers, user interface responsiveness significantly worse than other browsers, render times significantly worse than other browsers, or any other problem in Firefox?

If you're having problems with Firefox, you may want to try creating a new profile or other suggestions from the MozillaZine Knowledge Base. I see the suggestions help users all the time in the MozillaZine forums.

There was a thread on the Mozillazine forums about malicious JavaScript changing router settings about two years ago. Unfortunately, in October Mozillazine had a big foulup and many threads (and users, me included) were lost. I cannot find the thread now, but if I do I'll post back with a[n] URL. The thread's conclusion was that one should never leave the default password on the router.

There was a thread on the Mozillazine forums about malicious JavaScript changing router settings about two years ago. Unfortunately, in October Mozillazine had a big foulup and many threads (and users, me included) were lost. I cannot find the thread now, but if I do I'll post back with a[n] URL. The thread's conclusion was that one should never leave the default password on the router.

If Firefox crashes regularly on your computer, you should probably read the Firefox crashes article. It will probably help solve your problem.

Actually, it's not very labor intensive at all. See http://kb.mozillazine.org/Locking_preferences. The preference you need to lock is ("xpinstall.enabled", false).

Assuming your users don't have access to delete files from the program directory (or, if they do, otherwise aren't likely to go out of their way to look up how to undo this), this method should work. It took me about five minutes to create the file; then you just need to be able to deploy it. (We used a batch script.)

We distribute configuration changes to Firefox through user.js and userChrome.css; settings here override the user's other settings when the browser is restarted. (Of course, this means that everybody's profiles need to be stored with a standard profile name in a standardized location, which you have to be able to copy files to remotely.)

If these aren't secure enough for you, then you might try Mozilla's guide to Locking Preferences or try their client customization kit.

Yeah, it was David Hyatt who was working on getting Saf to pass (and got it to be the first browser to pass in any build, and the first to have a generally available release (i.e., a non-development build, even if public) -- the latter being the only thing that truly counts for passing the test).

http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008011 details the bug (in this case, it was the test itself that was wrong -- not the reference). The reference rendering for Acid3 is likely correct as the actual rendering isn't overly complex (the complexity is in the ECMAScript and DOM support), though with the complexity of some tests there could easily be bugs in the test again.

As many have said, people don't submit bug reports because only those that make finding a bug easy are accepted

1. Maybe this bug is fixed in the nightly build. [The same memory and CPU hogging bug has been reported many, many times over a period of six years.]
2. Yes, this bug exists, but other things are more important. [The bug eventually takes 100% of CPU power, and makes Windows XP unusable, even after Firefox is killed. The bug affects the heaviest users of Firefox.]
3. Yes, this bug exists, but it is not a common occurrence. [Numerous users have reported the bug. See the links.]
4. Works for me. [The bug is complicated to reproduce, so the developers did a simplified test, which didn't show the bug.]
5. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated. TalkBack does not generate a report if Firefox is hogging the CPU. TalkBack cannot generate a report if the bug takes 100% of the CPU time.]
6. If you would just give us more information, we would fix this bug. [They didn't bother to reproduce the bug using the detailed information provided.]
7. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
8. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
9. I don't like the way you worded your bug report. [So, he didn't read it or think about it.]
10. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
11. Many bugs that are filed aren't important to 99.99% of the users.
12. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instability is beginning to be reported in media such as Information Week. See the links to magazine articles in this Slashdot comment: Firefox is the most unstable program in common use.]
13. Your problem is probably caused by using extensions. [These are extensions advertised on the Firefox and Mozilla web site, and recommended.]
14. Your problem is probably caused by a corrupt profile. [The same bug has been reported many times over a period of five years. One of the reports discusses an extensive test in both Linux and Windows that used a completely clean installation of the operating systems, not just a clean profile. The CPU hogging bug and instability was just as severe.]
15. If you are technically knowledgeable, you can spend several hours (or days) trying to discover the problem: Standard diagnostic - Firefox. [Firefox has "Standard Diagnostics". It has become accepted that some users will have severe problems. !!! ]
16. I won't actually read the (many) bug reports, but I will give you some complicated technical speculation. [This pretends to be helpful but, on investigation, is shown to have nothing to do with the bugs.]
17. It's understandable that Firefox developers become defensive when users report so many problems.
18. To spend smart developers' time going over reports of bugs generated by analysis tools would be a waste. [There have been 3 analysis tools recently used to find Firefox bugs, and many have been found: 1) A special tool designed by a Firefox developer. 2) Software by Coverity. 3) Klocwork's K7.]
19. Your bug report was not specific enough. [Numerous conditions were listed which provide reliable ways to r

are available here http://wiki.mozilla.org/Firefox:2.0_Institutional_Deployment

And a great support site is here http://forums.mozillazine.org/viewforum.php?f=38

For example, in 6 years the CPU hogging and memory hogging bugs are still not fixed

I remain curious. How would one see one of these supposed CPU or memory hogging problems? If you can describe the circumstances under which the problem occurs, someone can file a bug report so the problem can be fixed. If no one can explain what the bug is, you should not be surprised if it has not been fixed.

On the other hand, perhaps you're experiencing a problem that is not a bug in Firefox that can be easily fixed by some of the suggestions in Reducing memory usage - Firefox or Firefox CPU usage.

If you are unable or unwilling to resolve the problems in Firefox, perhaps it's time to simply switch to another browser. There are plenty of other good ones out there. There's no sense in continuing to suffer from serious problems while using your browser.

Opera is able to restore sessions, but the Firefox session restore feature throws away URLs if response is slow. Why is that, when millions of dollars are spent on development each year?

Perhaps no one has yet filed a bug report on the issue.

For example, in 6 years the CPU hogging and memory hogging bugs are still not fixed

I remain curious. How would one see one of these supposed CPU or memory hogging problems? If you can describe the circumstances under which the problem occurs, someone can file a bug report so the problem can be fixed. If no one can explain what the bug is, you should not be surprised if it has not been fixed.

On the other hand, perhaps you're experiencing a problem that is not a bug in Firefox that can be easily fixed by some of the suggestions in Reducing memory usage - Firefox or Firefox CPU usage.

If you are unable or unwilling to resolve the problems in Firefox, perhaps it's time to simply switch to another browser. There are plenty of other good ones out there. There's no sense in continuing to suffer from serious problems while using your browser.

Opera is able to restore sessions, but the Firefox session restore feature throws away URLs if response is slow. Why is that, when millions of dollars are spent on development each year?

Perhaps no one has yet filed a bug report on the issue.

No, creating a new profile does not cause you to lose any information. You can import your old settings to the new profile.

The advice to create a new profile also has nothing to do with memory leaks in Mozilla software. If you're experiencing bugs in Mozilla software, you'll still see them with a new profile. If creating a new profile fixes a problem, it was due to a bad extension or other bad setting. In some rare situations, it may be possible that a perfectly reasonable setting triggers a bug in Firefox. If you see that is the case, simply point out the problem by posting to the MozillaZine forums or filing a bug report in Bugzilla, then the problem can be fixed.

If you still experience problems after creating a new profile and following the other basic advice in the Knowledge Base, and posting about the problem in the MozillaZine forums also doesn't help, then yes, a user should consider changing to another browser.

They have been spending lots of time fixing those issues. Are there any specific bug reports you think should be addressed? Any particular site or feature you're having a problem with?

If you cannot or will not track down the problems you're complaining about, and they persist even after creating a new profile and trying other fixes in the MozillaZine Knowledge Base and asking for help in the MozillaZine Forums, you should simply switch to another browser. Why put up with serious problems when there are so many other browsers to choose from?

They have been spending lots of time fixing those issues. Are there any specific bug reports you think should be addressed? Any particular site or feature you're having a problem with?

If you cannot or will not track down the problems you're complaining about, and they persist even after creating a new profile and trying other fixes in the MozillaZine Knowledge Base and asking for help in the MozillaZine Forums, you should simply switch to another browser. Why put up with serious problems when there are so many other browsers to choose from?

Warning: There is claims that that preference has been removed post-beta2. See the post by Littlemutt at http://forums.mozillazine.org/viewtopic.php?t=613781

I use a 3rd party build of Firefox, on my system I saw a ~25% speed increase in the test going from 12s on the standard firefox build to 9s on the third party build

They're not trying to make a browser for a freakin' mobile phone here ok?

Minimo and Maemo browser. Here is an article about Mozilla and mobile.

One of the claims of Opera's lawsuit is that Microsoft makes no attempt to comply with standards. Now that lawsuit looks utterly foolish. Opera is to blame. Normally when party A has a beef with party B, party A contacts party B so they can try to resolve the issue before running to the courts/commissions/government. If Opera had done that, they would've learned that IE8 would follow the CSS standards. But Opera didn't do that (or didn't care?) so filed a bogus suit out of willful ignorance. Opera is a laughing stock right now, and getting next to zero support for their suit, as shown by this mozilla blog entry:
http://weblogs.mozillazine.org/asa/archives/2007/12/opera_calls_for.html

1) Implement threading both between tab sessions and within tabs themselves

What does this mean? It's not like you can sprinkle "threading" onto an app and have it magically improve things. There is quite a lot of thought on the subject of concurrent execution within the context of a browser, but it's not as if there is an existing software pattern that will just fix the issue that I think you are referring to.

3) Implement some sort of standard memory/resource allocation/deallocation API for extensions so that people can bring up a standard window and see:

This would be cool, but, again, it's not like it's easy. An OS can't even reliably give you these stats. `kill -3`ing a process is about as close as it comes. Or am I misunderstanding what you are asking for?

1) Implement threading both between tab sessions and within tabs themselves

What does this mean? It's not like you can sprinkle "threading" onto an app and have it magically improve things. There is quite a lot of thought on the subject of concurrent execution within the context of a browser, but it's not as if there is an existing software pattern that will just fix the issue that I think you are referring to.

3) Implement some sort of standard memory/resource allocation/deallocation API for extensions so that people can bring up a standard window and see:

This would be cool, but, again, it's not like it's easy. An OS can't even reliably give you these stats. `kill -3`ing a process is about as close as it comes. Or am I misunderstanding what you are asking for?

I used to have a script that would download an unofficial nightly build of Firefox every morning when I logged in. A lot of the "unofficial" nightly builds will use up and coming features like newer Gecko engines, and have some non-standard optimizations turned on.

Look around here, and you should be able to find a frequently updated nightly build that uses Gecko 1.9. If you update frequently you'll definitely want to keep a backup of the last "good" install.

That being said: Konqueror! FTW!

This sounds like what you're talking about, albeit only for script.

XHTML V2 and related modules are officially supported by the W3C, and the related modules are becoming key ingredients for other XML specifications that the W3C maintains. Unfortunately, official W3C approval is no guarantee of support by major Web browsers.

It wouldn't be the first time browser vendors were ahead of official recommendations.

The FAQ doesn't even try to give a serious answer about the expected date of approval

Current browsers support both HTML V4 and XHTML V1.

Similarly, future browsers might support both HTML V5 and XHTML V2.

• Safari: For a long time, the HTML standards process has been moribund; the W3C's HTML Working Group has focused almost exclusively on XHTML2, a new standard that was highly incompatible with existing practice. The people working on the major browsers have largely abandoned the HTML Working Group.
• Opera: So, I don't think XHTML is a realistic option for the masses. HTML5 is it.
• Mozilla: In the near term, only Mozilla-based browsers come close to having all the integrated infrastructure needed by XHTML 2, and not all bundled by default. There is no sign of XHTML 2 support from Microsoft, Apple, and Opera.

Apparently that has been fixed now? A change on the way Vista stores settings for default browser it seems.

Actually, this page describes how to do what I want.

Here is more information from their knowledge base. According to that article it's caused by Adblock+ (0.7.5.2 and lower) and the Google toolbar. It lists two ways to fix it, first by using the File Types dialog and by editing the registry.

Try the suggestions from the MozillaZine Knowledge Base article Firefox crashes.

Firefox has an option to only send cookies to the originating site, but, because in this case third-party sites use JavaScript from Facebook's servers, the cookie can still be read. As you say, it would be nice if browsers could block this kind of stuff.

What you're describing is a common misconception of Ben Goodger's blog about the bfcache. Let me give you a few snippets from that post: "All versions of Firefox no doubt leak memory" and "What I think many people are talking about however with Firefox 1.5 is not really a memory leak at all. It is in fact a feature."

So, yes Firefox does leak memory. On the other hand, some people see the extra memory used by caching and mistake it for a memory leak. Some people see the memory wasted due to memory fragmentation and mistake it for a memory leak. And there are actual memory leaks also.

I'll repeat it again so it might sink in this time. Mozilla developers have never denied that there are leaks. If anyone says that Firefox doesn't leak memory, they're obviously incorrect. Go argue with the people who are stupidly claiming that Firefox doesn't leak memory. Don't argue with me, as I agree with you completely.

Did you notice the Flash animation on the right side of the page? That's what's consuming the CPU, not Firefox. You can read more about the issue in the Firefox CPU usage article in the MozillaZine Knowledge Base.

For more information, see this blog post from Asa Dotzler.

I think you're referring to caches. They are different from leaks in that caches are deliberately holding on to memory to improve performance. All browsers have caches, because performance would be unacceptable with no caching whatsoever. A leak is different in that it does not improve performance, but is only wasting memory. You can minimize the amount of memory Firefox uses for caching if you want.

According to the list of problematic extensions, IE Tab has a memory leak. Perhaps you should uninstall that extension.

I don't see that memory usage remains a problem for most users. It's just the vocal few who are having memory problems. The main problem is that these users assume this is part of the "normal" experience of using Firefox, so they complain that every user must also be seeing the same thing. They take no steps to fix or report their problems, as they consider the problem to be "well-known" and think developers must be idiots for not being able to see it.

If you're still having serious problems with Firefox, try creating a new profile and installing the Firefox 3 Beta. If you still have problems, discuss them on the MozillaZine Builds forum. If the problems do not get resolved, just switch to another browser. It's not normal to experience serious problems when browsing, so I don't see why anyone accepts it as part of the "normal" experience.

I agree that the damage to Firefox's reputation is already done. I've found that no matter how many reports come out that Firefox doesn't have a severe and obvious memory problem, the few reports that show a problem are the ones that become popular. If any of them just included instructions to reproduce the problem on other computers, those reports would be productive. Somehow, they always seem to leave that part out.

I don't see that memory usage remains a problem for most users. It's just the vocal few who are having memory problems. The main problem is that these users assume this is part of the "normal" experience of using Firefox, so they complain that every user must also be seeing the same thing. They take no steps to fix or report their problems, as they consider the problem to be "well-known" and think developers must be idiots for not being able to see it.

If you're still having serious problems with Firefox, try creating a new profile and installing the Firefox 3 Beta. If you still have problems, discuss them on the MozillaZine Builds forum. If the problems do not get resolved, just switch to another browser. It's not normal to experience serious problems when browsing, so I don't see why anyone accepts it as part of the "normal" experience.

I agree that the damage to Firefox's reputation is already done. I've found that no matter how many reports come out that Firefox doesn't have a severe and obvious memory problem, the few reports that show a problem are the ones that become popular. If any of them just included instructions to reproduce the problem on other computers, those reports would be productive. Somehow, they always seem to leave that part out.

You can find the results of a more extensive memory test here.

Open "about:blank" repeatedly and watch the memory footprint rise and rise.

Hhmm...

http://forums.mozillazine.org/viewtopic.php?t=543405