We're doing as much as we can to reduce those problems while Firefox is still single-process. For example, we recently started throttling timers in background tabs and added a sane web animation API. More and more internal APIs are asynchronous or interruptible. We've also reduced memory use quite a bit with Firefox 7; I think we use significantly less memory than Chrome in common cases now.

At the same time, we're also working on process separation. It looks like it will be ready to play with, perhaps even an option, in a few months. I don't think we'll enable it by default until we're comfortable with the tradeoff between memory use and responsiveness/stability.

And we're also working on a new programming language that could make it safe and sane to use "tasks" (likely mapping to threads) rather than processes, so we don't have to deal with that unhappy tradeoff :)

I'm curious about the change to rendering. It seems to me they're saying, "these OS layout engines (Quartz et al) are too slow - we'll just route around them".

Precisely the opposite. It's our previous abstraction layer that's too slow, and we're replacing it with a thinner one, starting with the easier things like Canvas. See Introducing the Azure project and Azure vs Cairo.

Does that still happen? I thought we fixed that a while ago, and made it show an error message instead of popping up the profile manager.

Actually, what I want from the Mozilla devs at the moment is not new features, but a solution to Firefox's memory problems.

Then you'll be happy to know that the "latest and greatest" includes some pretty big memory improvements. Do a find-in-page on The Burning Edge for "memory" or read Nick Nethercote's blog.

It seems that it's easier to motivate Mozilla developers to work on memory issues when the fixes will reach users in months rather than years.

I'm using Nightly (7) and I'm having trouble getting Firefox to use more than 400MB (explicit) even after a day of heavy use, with Gmail and Reader and Twitter as app tabs. You should try it out and report any bugs you encounter. Yes, we finally have tools that allow users like you to report useful memory leak bugs.

Or maybe it's a security hole in your extension that it prevents you from keeping Firefox up to date.

Good luck getting people to contribute to and use your "old and insecure" fork of Firefox.

Indeed. For my users, I'm tempted to say "Sorry, I can't support Firefox because Firefox doesn't support Firefox", and switch them all over to Opera.

How would that help? Opera doesn't provide security updates for old versions either.

fwiw, DreamHost says Ryan Cleary was behind DDoS attacks on DreamHost.

I'd be more worried about the senator who doesn't look at free porn on his home computer.

Where do you see Mozilla "jumping up and down shouting the version number"? The main mozilla.com page barely mentions it.

Perhaps browsers should let you modify the volume per hostname or per tab, since they are also application platforms.

There are some bugs related to sqlite memory use, bug 411894 and bug 650649.

I don't know why we bother caching parts of the sqlite files at all. That's what mmap and OS filesystem caches are for.

The good news is the sqlite memory use won't keep growing. At worst it will grow to about the size of the database, and then remain steady. It's only a significant fraction of Firefox's memory use when Firefox isn't using much memory.

That's not so great. If you upgrade to [Firefox 6] Aurora, and look in about:memory after doing that, where does Firefox think all the memory going?

On the other hand, fake-scan scams rely on Windows users' fear of Windows viruses in order to trick users into installing malware. I guess evil psychology tricks hurt users of both platforms.

Because each browser's JS engine is closely tied with its DOM, which is in turn closely tied with its layout engine. Otherwise it would be difficult to have efficient DOM calls and complete garbage collection.