I recently noted in Firefox 3.0 RC 2 that the sort order for autocompleting input fields is broken. In Firefox 2.x, items are sorted alphabetically (different from the insertion order scheme used in Firefox 1.x, if I recall correctly). Now, it appears that the items are sorted according to how they were inserted, with the most recent entries appearing on the bottom. This strange result unfortunately affects Googlebar Lite, beginning with Firefox 3 builds. I haven’t received any complaints about this at the moment, but I’m guessing that most people haven’t switched away from 2.x, so no one has caught it yet.

It’s possible that this issue is a valid Firefox bug. I see that bug 418343 has been written against the search autocomplete results, though I’m guessing it applies to all autocompleting elements (with the exception of the AwesomeBar).

The autocomplete textbox inherits the sortDirection property from the base XUL element, but I have yet to try setting that manually to see if it has any effect. And I’m not sure whether to set it on the textbox itself, or on one of the child elements that lives inside.

Hopefully setting this property will fix the issue, though I’m only given three sort options: ascending, descending, and natural. I’m guessing that the natural option is what I’m seeing now in Firefox 3, with newest at the bottom. One of the largest feature requests that I get for Googlebar Lite is to sort search history items in the order they were inserted, with newest at the top. While I may not be able to easily sort things like people want, I might at least be able to return to the behavior seen in 2.x.

Mozilla Developer News reports that Firefox 3 will be officially launched next Tuesday, June 17. Make sure you download your copy that day, to help Mozilla break the world download record. I’ve been using Firefox 3 for a while now, and it’s worlds better than Firefox 2 (which was already super awesome).

It’s official: I am switching to Firefox 3 RC1 as my primary web browser. All of the extensions I use are now compatible in some form or another (Firebug and Linkification are still in ‘beta’), so that’s no longer holding me back.

One interesting note about Firebug. The new version has removed the ‘Disable / Enable’ feature for individual sites. Or so I thought. This functionality has now been moved to the Network Monitor and Script Debugger sections of the extension. In other words, I can now explore the DOM tree for any site, without having to pay the performance hit from the network monitoring code. Woo-hoo!

The last few Firefox 3 nightly builds have changed the way SSL URI’s are displayed to the user. In Firefox 2, accessing a secure site results in a yellow background for the address bar (which I think is a particularly elegant solution). For reasons I don’t fully understand, Mozilla is getting rid of this implementation. In new Firefox 3 builds, the background of the ‘favicon’ will change depending on the security of the site. A blue background indicates an SSL secured site, while a green background indicates an EV SSL secured site. Moving the color to the favicon, in my opinion, makes things a little harder to understand. A heated debate about this inevitably appeared in the corresponding bug, and there will likely be more confusion over this in the future, as more public users begin to explore the Firefox 3 world. I fully expect an extension to ‘fix’ this feature, so all may not be lost. This is a very strange decision on Mozilla’s part, and it should be interesting to see what the end result is.

For the most part, I haven’t spent much time with Minefield. Firefox 2 works well enough for me that I haven’t had much desire to play around with the new stuff, especially seeing as many portions are inevitably either incomplete or broken. However, the recent beta 4 release prompted me to take it for a spin around the web. Here are a few thoughts on the latest build I’ve tested as of this writing (2008031205):

New Look

The new skin is interesting, but portions of it will definitely take some getting used to. Surely it’s not final (these things never are until the thing is actually released), so I’m hopeful there will still be a few tweaks. When using large toolbar buttons, the back button appears round, while the forward button is much smaller and rectangular; an odd pairing which is reminiscent of Internet Explorer 7. I tend to use the small toolbar buttons, so this change doesn’t affect me too much. The forward and back history menus have been consolidated into one menu (again, like IE7), which I think is a nice improvement. The new URL bar looks nice and provides a lot more information than the previous one did. A little star icon at the far right of the bar provides a quick means of bookmarking the current page, which is handy.

Improved Memory Usage

I put the new build through its paces at Google Maps, dragging around, zooming in and out, and generally trying to run up memory consumption (which I did successfully). After closing the corresponding tab, I noted that memory usage dropped considerably, and continued to decrease over time. The new garbage collection and memory defragmentation that has been implemented is clearly a big improvement. Firefox is still a hog, but it’s heading in the right direction.

Faster JavaScript

The JavaScript improvements which I recently mentioned are immediately noticeable. GMail and Google Maps feel a lot faster than they typically do, which is super great.

URL Bar Autocompletion

Autocompletion in the URL bar is now handled in a new (and exciting) way. As you type, matches are offered based on all text associated with a link. The page title, the URL itself, and bookmark keywords are all searched. Matched text can appear anywhere in the string, which is really handy.

Password Manager Prompts

The password manager now slides down from the top (like the information bar), so it’s not quite as intrusive. However, the handy keyboard shortcuts are no longer the same. In order to quickly answer the ‘Not Now’ choice, you have to press Alt+N instead of just N. This will take some getting used to.

Page Zoom

The new page zoom feature works really well. Images are magnified, as is the text on the page. There’s even an option to only zoom the text, leaving images alone. Pretty neat!

There are plenty of other changes in Minefield, so I recommend checking it out. I am starting to work on adding FF3 support to CoLT and Googlebar Lite, but it’s turning out to be a little more difficult than I initially thought. A host of code changes are needed in Googlebar Lite, since I’m currently using interfaces that are now deprecated. Hopefully I can get things updated in the near future.

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.