I triaged bugs back in 2000, too. What was your username or email address in Bugzilla? :)

Nowadays my focuses are security and finding bugs.

In 2009 I wrote about how to make triage more efficient and more effective. (Tyler linked to my post). And I actually triaged a subset of bugs that way when I was tasked with bringing down the number of crash bug reports.

What exactly do Mozilla do with 100 million dollars of tax-free revenue?

The first thing we do with it is to pay taxes. It was not trivial for us to figure out how to do that.

Are they building a war chest?

You can get a sense of how much we're saving by reading financial reports from previous years. To some extent, we're saving not because we want to save, but because we can only hire people so fast while maintaining quality and culture.

That'd be 500 full time employees at 100k per year with 50 million left over in case of emergencies.

500 full time Mozilla employees and contractors isn't far off.

I've heard a rule of thumb that once you throw in benefits, offices, and travel, the cost of employing someone is about twice their salary. I don't know whether that holds for Mozilla, which has generous employee benefits but many remote employees.

every single time, Firebug and Greasemonkey stop working.

If you use a beta version of Firefox and want to use Firebug, the Firebug developers say you should use the beta version of Firebug. It would be nice if Firefox Beta automatically went out and fetched the beta version of Firebug instead of just saying the version you have is incompatible.

Greasemonkey is often more compatible than its authors let on. I'm using it with Firefox 8 Nightly and it's working fine, despite being marked as only compatible with Firefox 5. I bet it would work in your Firefox 6 Beta just fine.

There's also a competitor to Greasemonkey called Scriptish that is marked as compatible with Firefox 6 beta. I've heard good things about it but haven't tried switching yet.

track add-ons better and not refuse to load them just because they haven't yet been certified to work

That's the plan!

AMO-hosted extensions that use APIs that haven't changed are automatically assumed to work. So are extensions developed using the new SDK.

To do it safely for other extensions, we'll need to gather data from beta users (like you -- thanks!) to find out whether the extension still does its job, whether it causes crashes (crash-stats correlations), and whether it causes other widespread problems (telemetry correlations).

Future beta versions of Firefox will probably ask you whether you also want to beta-test extensions that might not be compatible. For now you have to set a hidden pref to do that.

I'm pretty sure "__misaligned_access" in that stack trace is a red herring. Notice the large offsets and multiple frames blamed on the "same function". It's probably a section of ntoskrnl for which you don't have full symbols.

In theory you can get a decent stack trace (or even stack traces for all threads) by following the instructions on How to get a stacktrace with WinDbg. In theory. I tried once and got about as far as you did.

Does that mean the goal of Rust is to become part of Firefox at some point?

Yes, the hope is that parts of Firefox will begin to be written in Rust. I heard a rumor that we might replace our HTML parser first. (Our current HTML parser has one of the weirdest build requirements; it's written in a custom subset of Java that can be source-translated into C++.)

I had always wondered why Mozilla would suddenly become interested in writing a new programming language out of the blue

As opposed to digging deeper and deeper into our unhappy dialect of C++? ;)

Didn't seem like the sort of organization with so much excess resources to throw around that it would be useful to start spinning up such a thing

We're doing pretty okay on money for now :) Putting together a language research team doesn't compete directly with much of the other stuff we're doing, except maybe JS engine work. It's a long shot, but if it works succeeds, it will be worthwhile many times over.

instead of, say, buying more build slaves

IIRC, we were limited there by datacenter power or space. We recently got space in a data center in Phoenix, which should help a lot.

We were also limited there by trying to use the same hardware to test Firefox's performance on all desktop operating systems, which meant using a specific version of the Mac Mini for everything. And using the same hardware for both performance testing and unit testing. We're going to change that.

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.