Slashdot Mirror

Maybe we could debunk the Firefox is a memory hog hoax, too.

...no matter how many tabs I've got open via seesionsaver...

what about the solution posted on
http://forums.mozillazine.org/viewtopic.php?t=1369 81
doesn't this solve the problem, or did i not grasp the bug?

1. Maybe this bug is fixed in the nightly build.
2. Yes, this bug exists, but other things are more important.
3. 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.]
4. If you would just give us more information, we would fix this bug.
5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
8. 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.]
9. Many bugs that are filed aren't important to 99.99% of the users.
10. 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.]
11. Your problem is probably caused by using extensions. [These are extensions advertised on the Firefox and Mozilla web site, and recommended.]
12. Your problem is probably caused by a corrupt profile.
13. If you are technically knowledgeable, you can spend several hours trying to discover the problem: Standard diagnostic - Firefox. [Firefox has "Standard Diagnostics"! LOL.]
14. I won't actually read the (many) bug reports, but I will give you some complicated technical speculation which pretends to be helpful but, on investigation, is shown to have nothing to do with the bugs.
15. It's understandable that Firefox developers become defensive when users report so many problems.

Hi troll, I'm not going to bite but instead redirect you to a useful Firefox wiki.

You seem to have forgotten that one of those leaks is actually a feature.

lolwhat

He admits it himself, he just doesn't accept responsibility (as supposed head of QA) or say what he did/will do to change things like that happening again. Nor has he said (what happened to "open" source and meritocracy) who was responsible for not implementing the unit test that would have caught it - or what managerial changes have been made to ensure that unit tests get properly written. He is simply terrible at QA and much better at self promotion and marketing gimmicks.

http://weblogs.mozillazine.org/asa/archives/008125 .html

None of this means that he is evil or incompetant, but it does give the impression of someone who is insistently idiosyncratic. I can easily imagine that he'd be difficult to deal with.

Heh. He also has his own make version for some reason. Also, IIRC cdrecord doesn't (or didn't) support DVD recording except through a propietary program made by schilling. You needed to pay him money in order to get a license and a key. People had to code opens-source DVD extensions, and distros had to patch the cdrecord source with those extensions.

And then, there's the dev= issue. Schilling insist that the "right way" of using your burner is by passing the dev=1,2,3 argument, instead of dev=/dev/foo, and that the "right thing" to do is not to use a kernel interface to use the burner, but to let cdrecord internal libraries to access directly to the IDE/SCSI bus, like in the good old DOS days. When Suse patched their cdrecord version to use dev=/dev/foo directly, he wrote a linuxcheck() function that printks a warning when you're using a 2.6 kernel, and he "sub-licensed" that function with a GPL-incompatible statement: "you can't remove this function", just to try to force Suse and Redhat to include it.

Does it still have the 100% CPU utilization FEATURE that 1.5 has? I'd hate to lose the thrill of my system turning into a seized engine in quicksand... or the thrill of my less-computer-literate friends and relatives calling me for help on unfreezing their systems...

I wish these people would read some books on usability!

Theory is great, but experimental evidence (if gathered properly) trumps it every time. In this case, they did a usability study and found that many people were better able to deal with the close button on the tab.

Personally, I find it annoying, and prefer the old behavior. But it's also surprisingly easy to get used to after you use it for a while.

For the rest of my response, I'll follow your lead and truncate your post to soundbites.

...I've never seen it happen in Opera...

If you'd read my post, I said "mostly due to plugins" -- which you conveniently left out, and which affects Opera, Konqueror, and IE just as badly as Firefox. I've never had Firefox lock up hard past 1.0 that wasn't obviously related to a plugin (esp. Macromedia Flash or Adobe Acrobat) crashing the browser while loading/unloading a page. That's about as strong a promise as you can make when your product loads 3rd party native code.

...the problem is probably due to an extension...

There's a vast realm of difference between a plugin (executable native code) crashing the browser vs. an extension (XUL plus Javascript). The former crashing the browser is inevitable. The latter crashing the browser is sloppy, although some leaks are inevitable. (More on that in a bit.)

You said, "My gut says..."

Yup. I'm a programmer, have been since I was a wee one, been using C and C++ for 10 years, played with Object-Oriented Pascal back in the day, coded serious Java and Perl, written the occasional assembly, walked uphill in the snow both ways, etc. My gut is a finely crafted, state-of-the-art early warning system for catching bugs -- especially memory leaks, NULL pointer dereferences, double free() bugs, buffer overflows, yadda, after using C for that long. Like all heuristical systems it's far from perfect, with false positives and negatives both, but as an early warning system it works wonders. I haven't read the Firefox source code from top to bottom, although I'm fairly certain no lone human could, and I haven't even given it a serious skimming, so I don't have anything more than an educated guess to fly by. But I've seen some surprising interactions between "simple" GDI calls and Windows video card drivers, including previous ones where Firefox crashes under one driver version but runs fine after a driver upgrade (or even a downgrade). (This might or might not stem from the fact that, for speed, Firefox stores bitmaps in video texture RAM on Windows, and asks the X server to do the same on Linux.) I also know from past experience that HTML pages with <embed> and <object> tags crash all browsers far more often than HTML pages without, regardless of the browser in use (and not by virtue of the HTML itself, if you catch my drift). Video drivers and plugins are two likely suspects, and they're the first place I'd point gdb if I came across the RAM/CPU bug on my own machine.

...no one on the Mozilla Foundation team has investigated the CPU hogging bug...

Now, my memory may be faulty, but my entire post was based on reading someone's investigation into the RAM/CPU bug a few years back. Unfortunately, I didn't bookmark it and some creative googling hasn't turned it up. However, I did read Bugzilla in-depth to double check that I wasn't missing anything. (More on that in a bit.)

Your googling, OTOH, showed me two things: (1) a sizable number of people misinterpret the in-RAM cache and Back/Forward cache as memory leaks, not features; and (2) several extensions do/did cause Javascript memory leaks, but are being rooted out one by one (via debug builds and the Leak Monitor extension).

Just to make sure I wasn't missing anything, I did a fairly thorough sniff through Bugzilla. I searched all products for "leak", then personally read all 27 INVALID bugs and all 5 WONTFIX bugs. I didn't see one that wasn't legitimately so.

(Please note that Bugzilla forbids d

For the rest of my response, I'll follow your lead and truncate your post to soundbites.

...I've never seen it happen in Opera...

If you'd read my post, I said "mostly due to plugins" -- which you conveniently left out, and which affects Opera, Konqueror, and IE just as badly as Firefox. I've never had Firefox lock up hard past 1.0 that wasn't obviously related to a plugin (esp. Macromedia Flash or Adobe Acrobat) crashing the browser while loading/unloading a page. That's about as strong a promise as you can make when your product loads 3rd party native code.

...the problem is probably due to an extension...

There's a vast realm of difference between a plugin (executable native code) crashing the browser vs. an extension (XUL plus Javascript). The former crashing the browser is inevitable. The latter crashing the browser is sloppy, although some leaks are inevitable. (More on that in a bit.)

You said, "My gut says..."

Yup. I'm a programmer, have been since I was a wee one, been using C and C++ for 10 years, played with Object-Oriented Pascal back in the day, coded serious Java and Perl, written the occasional assembly, walked uphill in the snow both ways, etc. My gut is a finely crafted, state-of-the-art early warning system for catching bugs -- especially memory leaks, NULL pointer dereferences, double free() bugs, buffer overflows, yadda, after using C for that long. Like all heuristical systems it's far from perfect, with false positives and negatives both, but as an early warning system it works wonders. I haven't read the Firefox source code from top to bottom, although I'm fairly certain no lone human could, and I haven't even given it a serious skimming, so I don't have anything more than an educated guess to fly by. But I've seen some surprising interactions between "simple" GDI calls and Windows video card drivers, including previous ones where Firefox crashes under one driver version but runs fine after a driver upgrade (or even a downgrade). (This might or might not stem from the fact that, for speed, Firefox stores bitmaps in video texture RAM on Windows, and asks the X server to do the same on Linux.) I also know from past experience that HTML pages with <embed> and <object> tags crash all browsers far more often than HTML pages without, regardless of the browser in use (and not by virtue of the HTML itself, if you catch my drift). Video drivers and plugins are two likely suspects, and they're the first place I'd point gdb if I came across the RAM/CPU bug on my own machine.

...no one on the Mozilla Foundation team has investigated the CPU hogging bug...

Now, my memory may be faulty, but my entire post was based on reading someone's investigation into the RAM/CPU bug a few years back. Unfortunately, I didn't bookmark it and some creative googling hasn't turned it up. However, I did read Bugzilla in-depth to double check that I wasn't missing anything. (More on that in a bit.)

Your googling, OTOH, showed me two things: (1) a sizable number of people misinterpret the in-RAM cache and Back/Forward cache as memory leaks, not features; and (2) several extensions do/did cause Javascript memory leaks, but are being rooted out one by one (via debug builds and the Leak Monitor extension).

Just to make sure I wasn't missing anything, I did a fairly thorough sniff through Bugzilla. I searched all products for "leak", then personally read all 27 INVALID bugs and all 5 WONTFIX bugs. I didn't see one that wasn't legitimately so.

(Please note that Bugzilla forbids d

Instead of ftp.mozilla.org, try the mirror page – currently it seems to list beta 1, but you should be able to modify the download URL to get the en-US beta 2.

One small area that has had a reasonable amount of improvement in Firefox 2 is canvas support – I've been working on a canvas-based FPS engine and get about 50% better performance in FF2 than in FF1.5, as well as lots of fixed bugs and memory leaks.

Most major changes (like the new graphics infrastructure that'll help provide hardware accelerated rendering, full-page zooming, HTML inside SVG, better printing, etc) are being left for Firefox 3, but FF2 seems like a solid improvement over the previous version.

The canvas is actually a nice example of progress on the web. After too many years with very little going on, the major modern browsers developers (Mozilla, Opera, Apple) are working in the WHATWG to add new features – it's a balance between proprietary extensions and W3C-style specifications, with browsers implementing features at the same time as the spec is being written and guiding its development. There's room for competition between browsers in terms of feature support, and we don't have to wait years for the standards to be completed first – but it's hopefully without the old problems of those features being proprietary and poorly designed. For example, Opera 9 supports much of Web Forms 2.0 and the Mozilla developers are just starting work on it too; and it's also designed to be backward-compatible, so the new forms are still usable in all browsers and can be emulated in some (e.g. IE) with JavaScript. Firefox 2 seems to be the first browser with client-side session and persistent storage, but web sites written to benefit from that feature will be able to immediately work with future versions of e.g. Opera that support it too.

With the popularity of trends like AJAX encouraging people to think about new ways to interact with users over the web, and browsers adding features to expand the possibilities open to web developers, it'll be interesting to see what happens in the next few years.

browser.tabs.closeButtons
I don't know if there will be UI interface for it.

Adblock is a problematic extension when it comes to memory before the 042 nightly: http://kb.mozillazine.org/Problematic_extensions

You know, we've had three "patch regression" stories this month. Before the Ubuntu and Windows stories at hand, Mozilla had to turn around a quick point release for Firefox, to fix a regression that blocked the MMS protocol.

Despite everybody's best efforts and practices, sometimes a regression bug reaches production. And while the grandparent comment was a bit snarky about it, I would hope that whoever down-modded that comment did so to rebuke the tone, not to deny or supress the underlying issue.

Here is a pretty good resource for solving issues with Firefox:
http://kb.mozillazine.org/Category:Issues_(Firefox )

> Firefox also seems to be a huge memory hog,

See this article:
http://kb.mozillazine.org/Reducing_memory_usage_-_ Firefox

It will tell you how to recude memory usage and also points you to an extension which you can use to track down extensions that leak memory: http://dbaron.org/mozilla/leak-monitor/

"After a long day of coding, I like to kick back and sip an ice-cold bottle of Mozilla..."?

Actually, there was a time a few years ago that you could brew up a cup of Mozilla to keep yourself going through that coding session. Sadly, the company that used to do it (and contributed a percentage of his profits to Mozilla) has long since closed up shop.

"Firefox will come with RealNetwork applications" is the more logical construct (since it's Firefox that's being bundled, not the RealNetwork Applications!) I think what you meant to say is: "RealNetwork applications will NOT come bundled with Firefox downloads from mozilla.com)

Incidentally, you can read more about the deal (including some Slashdot bashing) at mozillaZine:

http://www.mozillazine.org/talkback.html?article=1 3674

Do you ever compact your folders? It's not on by default, so it's possible that your inbox is actually chock full of TONS of messages, but 99.9% of them are flagged for deletion and are hidden.

right click your inbox and select 'compact this folder'.

more details, and instructions for automatic compaction:
      http://kb.mozillazine.org/Compacting_folders

http://kb.mozillazine.org/Reducing_memory_usage_-_ Firefox

I know this will hardly solve all your problems, but IE Tab is known to leak memory.

That's quite sad; it is a rather useful extension.

I have really been waiting for this build of Thunderbird. It finally includes message tagging, which is something that I've been wanting natively in Thunderbird for a long time. Tagging now also apparently works with IMAP connections, although at least some users are having some problems with that feature. (Bug #344290).

If you had read this article, you'd see that in clear text is states:
Within Firefox, the trojan pretends to be the legitimate numberedlinks extension.

The extension itself is not the problem. The trojan creator just decided to have his extension pose as another in an attempt to be "inconspicous".

This MozillaZine article has lots more on the trogan horse, including instructions for spotting if you have it.

• Both removing and restoring IE is risky and difficult. IE is complex with extensive hooks built into Windows, for efficiency and functionality. Thus unplugging it from your system may impact Internet connectivity, Windows functionality, and break functionality in Microsoft Office and non-MS products.
  
• IE is more than a browser, it is the foundation for Internet functionality in Windows.
  

Come back when you understand the difference between disk caching and memory caching. So what if you've gone to more pages in FF? The files are cached to disk not memory.

http://www.mozillazine.org/talkback.html?article=6 567

http://forums.mozillazine.org/viewtopic.php?t=1720 41 I agree, 1.5's memory caching uses up a lot of memory, but if you're literate enough to notice that, you should be able to use a search engine and figure out how to tweak it, assuming it disagrees with you at all. I have left it as is up till now, and while I agree that firefox has some defaults that I don't like, it's still better than using IE. I don't understand how someone can rationalize using IE 6 at all.

OK, even before googgling for it, i KNEW you were from Sweden, there's simply no other countries in the world where you can get that kind of subscriptions for cheap.

Who's waiting? What gave you that idea? The fact is, Acid2 got released at the worst possible time for Gecko development -- right in the middle of a beta cycle. Since fixing all the Acid2 bugs requires fundamental architecture work, that meant that to fix them Gecko had to finish the beta cycle, ship a 1.8 final, _then_ start taking the fixes for Acid2 stuff. And such fixes are happening. The loading rewrite fixed most of the issues; the painting rewrite fixes more, and the reflow rewrite will fix the rest once it's done. But given how testing happens and how fragile most web content is, the first of these three changes probably needs 2-3 months of testing before it could possibly be shippable in stable form; the other two need more; I'd estimate 4-5 months of testing (and the reflow rewrite is not close to being finished yet). All of which means that targeting 2007 Q1 is about as well as could be done; figure another 2-3 months from now to finish the work, then 4-5 months to test, that puts us at end of 2006 for actually shipping. And that assumes that nothing else gets worked on but Acid2 issues.

Seems that Firefox 1.5 is a lot more aggressive at caching pages than previous versions... Also, the ammount of memory that will be used for this purpose depends on the total memory of your system.

You can find ways to configure that here.

Also, if you were using extensions (you already said you don't, but I'm adding this for reference) a good way to detect memory leaks is to use the Leak Monitor Extension.

Have you mucked with the following setting in about:config?

browser.sessionhistory.max_total_viewers
When set to "-1", Firefox assigns it a value based on your total amount of RAM. Setting it to a lower value such as 2 or 4 should result in less memory used. Especially if you are a window and tab fiend (I typically have multiple windows each with a dozen tabs open). The Mozilla site has details on how this setting works.

(Firefox's algorithm for determining max_total_viewers seems to be a bit aggressive for larger amounts of system RAM. One could argue that it makes the erroneous assumption that total RAM equates to useable RAM. Just because I have 1GB of system RAM doesn't mean that I want Firefox to use 1/3 of that.)

Safari pisses me off though because lack of design mode is a major flaw...

From Surfin' Safari, April 15 2005:

Safari 1.3 supports HTML editing, both at the Objective-C WebKit API level and using contenteditable and designMode in a Web page.

If you've installed Apple's OS X updates, you should be on Safari 1.3 even if you're still running Panther. Tiger has Safari 2 by default (IIRC).

You don't need an extension for that; in userChrome.css add this code, changing the number if you want: /* resize search bar */
#searchbar {
    width: 300px !important;
}

The reason I switched to Firefox wasn't because of the neat features, it was because it used less memory and was significantly faster than IE. With every release Firefox has gotten more and more bloated, to the point that it is taking 42mb of RAM to display only this thread on Slashdot. IE is taking 22mb to do the exact same thing. That's just rediculous.

Have you mucked with?

config.trim_on_minimize = true
(Useful in some scenarios when nothing else works.)

browser.sessionhistory.max_total_viewers
(A better thing to muck with. When set to "-1", Firefox assigns it a value based on your total amount of RAM, I think. Setting it to a lower value such as 2 or 4 should result in less memory used. The Mozilla site has details on how this setting works.)

Changing the second item from the default (-1) to a lower value (2) made a big difference in the amount of RAM that Firefox was chewing up on my system.

-Eric

This stubborn attitude among the Moz community that... integration with Windows authentication == bad

Mozilla has included NTLM authentication for years. Even non-Windows versions have supported it since November '03, a year before Firefox 1.0 shipped.

Admittedly, I haven't tested this since we don't have a windows-auth-based intranet, but assuming it works... is there some other aspect of Windows authentication that you're thinking of?

If I leave my FireFox pointing at a auto-refreshing page for a couple of days it *will* OOM my machine

It might not be the best solution in general, but firefox has several settings to limit it's memory usage if you run it in non-typical situations. The relevant settings are really easy to google (first hit for 'firefox "memory usage"'), surely quicker than writing your post ;)

There are lots of extensions with memory leaks and other serious problems. Be sure you're not using an extension on that list if you're having problems.

Plugins, especially Flash, have also been known to cause problems such as high memory use and 100% CPU use after waking up from hiberation. Be sure to get the latest Macromedia, Java, and Acrobat plugins.

As it so happens, the widgets are native. Mozilla exposes the underlying implementation. Which is why buttons look like Windows, Mac, or GTK+ buttons. The caveat to this is that you can create XUL buttons/components that are entirely virtual. These components are generally used to produce skins like that used in Firefox. But most XUL applications actually rely on the native components instead. Which is why the Amazon browser I linked to looks like a native Windows app.

Actually, from what I know, that is *not* true. Firefox has been criticized in the past for 'not looking quite right' on most platforms. Someone made a hack awhile ago to make the buttons look more accurate in OS X (*)...and there was much grief had over the appearance of the menus on the "Classic" view of XP. Firefox had designed their menu theme/XUL for the eye candy "Luna" view/theme of XP, and the menu items had the wrong pixel height for Classic. Personally, I can't stand that hideous theme, and so I use Classic on my XP box at work. To make it right, I used the extension cited on this MozillaZine KB article (though I barely noticed the difference). Camino uses Cocoa for its widgets, and so is 'native,' while Firefox on OS X will be transitioning to this at some point in the future. (3.0?)

I found the OS X story: http://www.hicksdesign.co.uk/journal/native-lookin g-firefox-os-x-widgets

The W3C publishes their specs; Microsoft does not. If they did [emphasis mine], I'm sure the Mozilla folks would be more than happy to implement it. As it stands, they're forced to try and emulate some of IE's bugs and quirks in order to render poorly-written, IE-only pages correctly.

But as I pointed out earlier in the discussion, they generally haven't done this.

He said that if Microsoft published specifications for MS-HTML, MS-CSS, etc, Mozilla might do something about it. Microsoft leaves a lot of things undocumented, so pointing out that Mozilla hasn't been forthcoming with support for these things doesn't contradict what he said.

Historically, their attitude has been that they would support only the "official" (i.e., W3C and such) specs, and would not implement any concessions to IE compatibility.

This is not the case. Their main focus is obviously on standards, and if the standard way of doing something conflicts with the Microsoft way of doing something, they tend to pick the standard way. But Mozilla have implemented plenty of stuff in the name of compatibility with Internet Explorer. Off the top of my head, there's document.all, favicons, two quirks modes and XMLHttpRequest. I'm sure there's more.

For all the bitching some people have been doing in this discussion about MS not documenting anything, they've also been bitching about IE6 has been standing still for years. It's not like there's a moving target to emulate, and the main differences are well enough known that pro web developers use them on auto-pilot these days!

There's a difference between web developers being able to work around issues and browser developers being able to correctly emulate issues. Compare, for example Microsoft's documentation for hasLayout, and its reverse-engineered description. This one facet of rendering has huge implications on layout, yet it remained an undocumented mystery for five years and still hasn't been totally cracked. Or look at Hixie's description of the way Internet Explorer comes with a DOM tree that isn't actually a tree. Or look at Hyatt's description of the "residual style" problem.

Mozilla and other browser developers already spend plenty of time reverse-engineering Internet Explorer. Are you really criticising them for choosing to implement some standards stuff too rather than spending 100% of their time on reverse-engineering Internet Explorer's crazy behaviour?

Looks like the Gecko folks don't care for people running Win98/ME either.
http://www.mozillazine.org/talkback.html?article=8 887

See my blogpost for the argument why.

Gerv

Google making firefox extensions? Maybe I'm retarded, but this is the first I've seen.

Maybe I'm retarded, but that didn't seem sarcastic to me, so here are some other firefox extensions from google. The "beta" (yeah, google loves the beta) version of google toolbar for firefox was released on July 7th, 2005.

Are we getting slashdot articles for each verion bump of the mozilla products?

Apparently not, since Seamonkey has also been updated.

Actually, there is a development version of spellbound that works with Firefox 1.5.0.x. It's quite useful, and has some nice features. You can get it here.

The install link is a little difficult to find, but look for "Install SpellBound Dev" near the end of the first message.

This works for me, but as always, your mileage may vary

This is known and actually a feature, which can be turned off:

http://weblogs.mozillazine.org/ben/archives/009749 .html

http://forums.mozillazine.org/viewtopic.php?t=3890 71&

OpenLaszlo certainly could target XUL eventually, but the demand for and installed base of Flash and DHTML is much larger, so Laszlo Systems decided to put their resources into targeting those platforms first.

Brendan Eich thinks OpenLaszlo supporting XUL would be a great idea, too. The recent developments for supporting multiple runtimes are intended to make it easier to target XUL and other platforms, and since OpenLaszlo is open source, your contributions towards supporting XUL would certainly be appreciated!

-Don