nice... does that include installer?

While I agree that the filesize reduction never hurts (and congratulations to ben for the smaller footprint, it's appreciated)... this begs the question why time is being spent on something trivial like this instead of crasher bugs, especially with 0.9 due out in June?

I wish the password manager were nearly as decent. It's kept me from upgrading from Firebird 0.6.1+. I've tried later builds (even the suite!) a few times but each time has returned to FB very quickly. That and autocomplete really tick me off.

tmeader:
You have to understand the Firefox development philosophy: cater to the average end user.

The end user cares when he's expected to download large software in order to test something for which he already has a perfectly workable alternative in IE. The end user usually has to go out of his way to install Firefox; the less out of his way he goes, the more likely he is to stick. A shorter, smaller download is less out of his way.

Here's the most important part of my response to your question: the end user doesn't care about crashing as long as it doesn't happen to him. Most crashers simply aren't a priority because they don't happen to a large number of users.

The super-obvious crashers that affect nearly every user within minutes are almost *always* fixed quickly. The somewhat-obvious ones are the topcrash bugs that are being worked through by other devs as 1.7 approaches release. The non-obvious ones aren't likely to be encountered by new users. As for Ben and crashers, I don't know how much experience Ben has at the backend coding required to fix most crashers. In any case he's the Firefox dev, and the Firefox dev codes Firefox, not the backend (usually - extensions/profiles/etc. are a notable exception). The more he fixes the backend, the less he fixes the bugs in the frontend.

<flamebait why="cant-resist">If you want backend crasher fixes more than you want frontend polish/feature fixes, stick with Seamonkey.</flamebait>

Ben is quite competent to fix back-end bugs (including crashers) in a good bit of back-end code. You're right that it's a matter of priorities, though -- Ben's priority is creating the best app he can, while other people's priority is to create the best rendering engine they can. With some cooperation, both win.

Thanks Boris :-)

I have a few crasher bugs on my 0.9+ list, and they're going to get attention before the release. Every now and then I'll diverge from my list of immediate priorities to do something new, interesting or fun, especially where there's a low risk and high reward. This was one such area. I want to thank Glen Johnson, Igor Pavlov and Heather Meeker for assisting with this particular change.

Okay, wasn't quite sure about that. I figured he probably was given everything he's had to implement for the extension/themes manager, but I didn't want to assume too much. I tried to word it as delicately as possible in any case by simply saying "I don't know".

Oh excellent, we're using LZMA in the setup program now. I've seen NSIS and Inno Setup adopt LZMA and the footprints of the packages they produce have dropped significantly. Congratulations to Ben - a 25% drop in download size is no mean feat.

With this new compression format, will we still be able to use a tool like mozip.exe to update some files in it in order to make localized installers? It will cause a lot of harm on translators if a full recompilation happen to be necessary, since we don't have the resources to do that.

Furthermore, for Firefox 0.8, we managed to add our xpi language pack inside the installer. We are not even sure to be able to do that with the new extension scheme. A clarification on how it's going to work now would be useful.

Well I just found out that I could *read* the files from 7-zip (which is better than before) but not *update* them. We'd really need such a tool.

Will the Mozilla Suite also begin to use the 7zip algorithm to minimize the size of the installer package?