A special nightly build of Firefox 3.0 has been released that greatly improves JavaScript performance. The build was run against the SunSpider JavaScript Benchmark, and the results are really surprising. From the article:

1. Firefox 3 Nightly (PGO Optimized): 7263.8ms
2. Firefox 3 Nightly (02/25/2008 build): 8219.4ms
3. Opera 9.5.9807 Beta: 10824.0ms
4. Firefox 3 Beta 3: 16080.6ms
5. Safari 3.0.4 Beta: 18012.6ms
6. Firefox 2.0.0.12: 29376.4ms
7. Internet Explorer 7: 72375.0ms

This optimized build is nearly 4 times faster than the current release of Firefox, and 10 times faster than IE 7; pretty cool!

I have yet to switch to Firefox 3, mostly because lots of my favorite extensions don't yet work (including the ones I've written). There are a handful of changes that have to be made in order for extensions to work in the new environment, some of which aren't exactly trivial. As we get closer to an actual release, I'll do my best to update my extensions.

There's a really great article over at Stuart Parmenter's blog discussing memory fragmentation in Firefox. This phenomenon is what's causing Firefox to appear to consume so much memory. Most folks simply assume that Firefox leaks memory, mostly because they probably don't understand what a memory leak is. Although Firefox did at one point have a number of memory leaks, the majority of them have been plugged (see this article by Jesse Ruderman for further details).

It's great to see that someone is investigating this issue, and I find it very interesting that it's a fragmentation problem that's causing things to look bad. Hopefully we can see some fixes for this issue in the near future, and Firefox can get a better foothold in this department.

Update: There's a great followup article that shows some of the preliminary work going on to solve this problem.

I recently ran into a problem on my system where all the HTML document icons had been reset to the generic default icon:

Apparently, the Minefield build of Firefox had at some point corrupted this icon. I found that I was unable to change or reset the icon through the Folder Options » File Types dialog in Windows Explorer. No matter what I tried, I couldn't restore the icon, and it drove me nuts. Then I figured out what to do, thanks to this forum post at MozillaZine:

1. Open RegEdit.
2. Browse to the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML registry branch.
3. Delete the ShellEx\IconHandler registry key entry.
4. Close RegEdit.
5. In Windows Explorer, browse to the Documents and Settings\{username}\Local Settings\Application Data folder.
6. Delete the iconcache.db file. It's hidden, so you may need to tweak your Windows Explorer settings to see it.
7. Reboot.

Problem solved!

Firefox 3 will include several heavy-hitting changes to extension development, some of which will cause existing extensions to break. Let's take a look at what's changing, to get an idea of what to expect from a development point of view:

New APIs One big change that will likely break some existing extensions are the new Firefox APIs being introduced in 3.0. All of the bookmark and history APIs are changing radically, with the introduction of the new Places architecture. As such, any extensions that make use of these will need substantial work to run properly in Firefox 3. Similarly, any extensions that use the Password storage functionality in Firefox will need changes (a new login manager will be used to handle stored passwords). It remains to be seen how one will develop an extension that will be compatible across all versions of Firefox. I haven't seen any mention of simply deprecating the existing API calls, though I would hope that's what the developers would do.

Secure Updates Firefox 3 will require that all extension updates be provided over a secure channel, to avoid man-in-the-middle attacks. This means that if you are not using the official addons.mozilla.org website to host your extensions, you must provide your own secure method of distributing updates. One has several options for doing this:

1. The updateURL must either use https or not be provided at all.

This method assumes that you either host with the official site (thereby not using an updateURL value at all), or you are willing to host your extensions from a secure location using https. The latter option will likely cost you money, while the former forces you to use a website beyond your personal control.

2. The updateURL uses http and the updateKey entry is specified.

This second option seems a little easier to swallow, though it will involve a little extra effort on the behalf of extension developers. First, an updateKey value must be provided in your extension's install.rdf file. Second, a digital signature must also be included in the update manifest; otherwise, the update will be rejected. Your updateLink value can either use https, or it can use http while providing an updateHash value. The updateHash value can be generated using either a sha1, sha256, sha384, or sha512 hash algorithm. But take note: you should not use sha384 or sha512 as of this writing. This forum thread mentions bug 383390, in which both sha384 and sha512 values are incorrectly truncated by Firefox 2.x (making backwards compatibility a problem).

Some further information about this new signing process can be found here.

Other Changes The two items above aren't the only changes coming down the pipeline for extension development, but they are the largest changes that I can see. A document detailing the new items is available, and should (hopefully) be updated as 3.0 nears an actual release date. It looks like extension developers will have a fair amount of work coming up, but I think these changes will be beneficial in the long run. How well the community accepts these changes remains to be seen.

A recent article at Indistinguishable from Jesse gives some updates on the current state of memory management in Firefox. There are some exciting improvements coming in Firefox 3, which should be a boon to many users. One of these days, when I get a free chance, I'd like to examine my extensions with the leak-gauge.pl script. I'm not 100% sure that there isn't a leak or two in Googlebar Lite, though I've done my best to be careful.

In entirely unrelated news:

• WordPress 2.3 has been released. I'll probably upgrade sometime this week.
• I just got a new 80 GB iPod. Pictures, reviews, and thoughts will appear throughout the week, so stay tuned.

One nice thing about the xkcd web comic, is that each comic's image has an additional joke or tidbit of information hidden away in an HTML title attribute. Hover your mouse over it for a second or two, and you'll see the joke. Sometimes, the text is fairly lengthy, as in this example. Unfortunately, Firefox only shows one line of text in a title tooltip, so any lengthy amounts of text get cut off with an ellipsis.

Thankfully, bug 218223 was filed way back in 2003 (as a Firebird equivalent of a bug posted in 2000). Now, 7 years later, a fix has been implemented. Firefox 3.0 will include this fix, much to my delight. This just might be enough to make me switch to the alpha builds of 3.0 for my daily browsing habits.

Update: I've found an extension that fixes this problem. Woo-hoo!

Last Wednesday was apparently a freeze day for the Gecko 1.9 rendering engine (which will appear in Firefox 3). A laundry list of new features have been added, as can be seen from the most recent nightly build report. Full page zoom is one of the biggest new features coming, though it has not yet been enabled via the GUI (you have to download a separate test extension to play around with it).

One particularly nasty regression (bug 390451) lurks in the nightly builds, so I'm not planning on switching my base install to this alpha. But it looks like it won't be much longer before we can enjoy some new Firefox features.

MozillaZine has announced that Firefox 2.0.0.5 has been released (though, as of this writing, I still don't see it via auto-update). I enjoy looking through change logs (weird as that may seem), so for every new Firefox release, I take a look at Bugzilla to figure out what has been fixed and what is new. Here's how I do it:

1. Browse to the BugZilla keywords description page (the link to this page is also available on the advanced search form).
2. Look for the "fixed[versionNumberHere]" and "verified[versionNumberHere]" keywords. Note that the [versionNumberHere] bit refers to the Gecko version number, not the Firefox version number. For example, Firefox 2.0.0.5 uses Gecko version 1.8.1.5 (as you might guess, the 2.0 release used 1.8.1). Firefox 3 will use Gecko 1.9.
3. Out to the right of each keyword, you should see a count of the total bugs that particular keyword corresponds to. Click that number, and you will see all of the bugs that use the specified keyword.

Here are the fixed bugs and verified bugs for 2.0.0.5. If you really want to get clever, you can combine these keywords together (separated by a comma) on the advanced BugZilla search page. You'll need to tweak some of the default settings on that form to get it to work, but it can be done (as this query for Firefox 1.5.0.5 indicates).

There are two special notes about doing things this way:

1. These queries are looking at fixes in the Gecko engine. As such, bug fixes for Thunderbird and Seamonkey will also show up.
2. You may not see everything, particularly high-risk security fixes. For all security changes, see the known vulnerabilities page.

I just read an interesting article over at Wired that essentially asks "Is Firefox Getting Bloated?" The article compares Firefox to SeaMonkey. I was a Mozilla browser user well before it was named "SeaMonkey", and well before Firefox 1.0 was released. During that time, I really came to despise the bloat in the application. Firefox was an incredible breath of fresh air when it was released: light-weight and responsive.

Personally, I feel that Firefox still exhibits both qualities. But I can see the argument made by the Wired article. Additional features, some of which many users may not actually care about, are creeping into the code base. Built-in support for microformats (something that I still don't fully understand) is coming in Firefox 3.0. Do users really need this? Mozilla apparently thinks so. Many users may disagree.

There are certainly areas where Firefox could improve (in-browser support for both Java applets and PDF files are horrible). But I think Firefox is in great shape now. One thing I know for certain is that I'm never going back to Internet Explorer. (Side Note: I recently installed IE 7 on my work laptop ... man, is it horrible.)

What do you think? Is Firefox too bloated? Too lean? Just right?

Mark Pilgrim just recently patched a long-standing bug in Firefox (the fix will appear in Firefox 3). Currently, there is no way a user can disable timed redirects through META refresh elements. This becomes a gigantic problem to blind users who utilize screen-reader software. By the time the screen reader starts reporting what's on screen, the page changes unexpectedly.

Beginning in Firefox 3, users will have the option of being warned when such refresh event takes place. A notification bar, just like the one used to alert the user of blocked pop-up ads, will appear when a META refresh takes place. The user will then be able to click a button to allow the event. Note that this new system will be disabled by default, meaning that everything will act as it does today in Firefox 2. Also note that JavaScript refreshes are not handled by this fix.

What I find most intriguing about this new system is that the notification bar appears just like an ALERT to assistive software. Mark has a blog post that goes into way more detail on the fix, so check it out if you're interested. It's really good to see Firefox making strides in this area. Yet one more reason that Firefox 3 will be super awesome.

A new build of Firefox is now available, so make sure you update. There are tons of fixes and improvements in this release; watered down release notes are also available.

I don't fully understand why people get so upset about the supposed "memory leaks" in Firefox. While I don't disagree that an application as large as Firefox could have memory management issues, I severely question the reports out there that indicate that Firefox eats up hundreds of megabytes of memory without ever releasing it. I use Firefox every single day for many hours, and I have never run into such a problem. In fact, what most people are complaining about is actually a feature.

That aside, let's assume that Firefox does indeed leak small amounts of memory here or there. What would it matter? Sure it might be sloppy programming practice. It's certainly not fair to eat shared resources that you'll never return. But under what circumstances might you be hindered from doing work on your computer because Firefox is "consuming" one or two hundred megabytes of RAM? What memory intensive operations are people constantly doing that causes them fume over this perceived problem? I can think of no single instance of computing that would both consume the entire system's memory, and be common enough that everyone encounters it on a daily basis. Granted, gaming might be one exception, but not everyone does that.

So my question is this: why care? Who cares that Firefox might use up to 200 megabytes of memory? Memory is cheap. If you're that concerned about the memory usage of your applications, you clearly don't have enough in your system. Just 1 gigabyte is more than enough for today's environment, and NewEgg has 1 GB modules for as little as $80. If you're complaining, just go for the upgrade; you'll be glad you did.

If you've been holding out for Firefox 2.0 (although why would you?), you'll be glad to know that Firefox 2.0 is now available. Lots of new goodies in this release: inline spell checking (the greatest feature yet), better tabbed browsing, session saver, and more. It doesn't get much better than this (until Firefox 3.0, that is).

While you're upgrading, make sure you have the latest versions of CoLT and Googlebar Lite.

With Firefox 2.0 RC1 on the horizon (the branch apparently froze last night for check-ins), I think it's time for another of my opinionated views on the new Firefox theme. I have mentioned before that the new theme looked pretty bad, and apparently a number of people agreed. Thankfully, the theme was revamped in the September 11 nightly builds, and it looks a lot better. But people are still complaining. I like the new 2.0 theme much better than the previous attempt, but I still feel the Firefox 1.5 look and feel is ideal. If it ain't broke, don't fix it.

So this leads to my main point: themes (or skins, whatever you want to call them) just seem wrong. So much time, energy, and development effort gets put into how stuff looks. Couldn't all of that be better spent in making Firefox better than it is today? Let's have faster start up times. The Places feature looks cool. And I'm sure there are other great ideas on the horizon. Can't we work on those instead of arguing about the icon used for the "Home" button?

At some level, a certain look will always have problems. One can't please everyone all the time, especially when it comes to looks; everyone's idea of beauty is different. So, set a look that most everyone agrees on (e.g. the current Firefox 1.5 theme) and leave it alone! Put all of the development effort on cooler features, not on shinier icons. In the end, I think everyone will be happier.

The second beta build of "Bon Echo" (what will become Firefox 2.0) is nearing completion, so I am officially switching to the nightly builds for my browsing needs. And I've already been quite pleased. By default, the nightly builds come configured to use the nightly update channel. Through this channel, you can receive each day's updates just by using the Help » Check for Updates... menu item in Firefox. They get downloaded, applied, and the browser is restarted. And with the new session saver feature in Firefox, you start right back where you left off when you downloaded the updates. How cool is that?

I still dislike the theme, and the list of bugs written against it continues to grow. Thankfully, the list of fixes is also seeing some growth. Hopefully things can get polished up by release time.

Sometime at the end of this week, or perhaps this weekend, I will be updating both CoLT and Googlebar Lite to work in the beta 2 builds (stupid maxVersion, grumble, grumble).

The new look and feel coming in Firefox 2.0 recently landed on one of the branch builds, so I downloaded one this weekend's builds and tried it out. My verdict? It has a long way to go before public consumption. In other words, it's pure crap in its current form.

A preview of the new theme is available over at the Mozilla wiki, and it looks pretty nice. Too bad the real thing looks nothing like that. Every icon looks grayed out, there are toolbar button hovering problems, widgets aren't properly aligned, etc. A catch-all bug over at Bugzilla has been filed for the new theme and, as of this writing, there are 38 dependencies (38 other bugs) written against the new theme (and only one has been fixed so far). That list has grown steadily over the past few days, and I can only imagine that it will continue to do so. I'm excited about Firefox 2.0, but if Mozilla screws up something this basic, it will certainly be a disappointment.

In somewhat happier news, a bug that's been around for some time has just been fixed in today's branch build. Bug 318793, Firefox caches extension update file, has been a minor thorn in my side for a while. I'm glad to see that this issue has received the attention it so sorely deserved.

Last night I posted a Firefox profile tutorial. The guide describes what profiles are, what they are good for, and how you can make use of them. I'll probably add to it over the next week or two. Some troubleshooting tips would make a good addition, and hopefully some readers will have suggestions on ways I can improve things. As always, let me know of any problems you might find.

Bug 343825, "Enable official branding and set version to Firefox 2 Beta 1 for upcoming release", was recently checked in to the 1.8.1 branch. This can only be good news, and a sign that the first beta build of 2.0 is on the verge of being released. Perusing through the change logs over at The Burning Edge, as well as the nightly build notices in the Firefox Builds forum at MozillaZine, yields some cool new features and fixes. The ability to undo closing a tab has recently been added, although you should be forewarned of bug 343801, which causes the history menu to intermittently disappear. Also, passwords are now auto-filled before all images are loaded. This is a great bug fix; no more eBay login trouble!

I am really excited about Firefox 2.0, and when the first beta is officially released, I'll certainly switch over. The nightly builds have been getting more and more stable, and they're certainly a joy to use. Thankfully, release day is only getting closer.

Bug 242207 was recently fixed on the Firefox branch, which means it'll make it into Firefox 2.0. This is great news, especially since I run into this problem all the time. The issue is that removing an entry from your address bar using Shift+Delete occasionally nukes your browser history. I can't tell you how many times I've run into this and then wondered what was causing my history to get lost. It's nice to see that someone has found the problem.

I've just installed the latest alpha build of Firefox 2.0, and things are looking real good. The Burning Edge has a change log for this latest release, displaying what's new between these alpha builds and the current 1.5.0.x line of Firefox browsers. Alpha 3 adds session saver support, anti-phishing support, search suggestions in the default search box, and more. If it proves stable enough, I might just switch to this alpha build for my main browsing platform. The inline spell checking feature is great!