In their march to copy Google Chrome, Mozilla is moving Firefox to a multi-process architecture. The code name for this project is Electrolysis. As of this writing, this project's integration target for released levels of Firefox is at the end of 2015. Dates can always slip, and are likely to, but that target seems real soon now.

Frustratingly, Mozilla has been surprisingly quiet about this upcoming change, at least from a developer standpoint. For months the Mozilla Add-ons Blog has promised upcoming articles on the changes necessary for add-on authors, but as of this writing, nothing has appeared. What documentation does exist is, as usual, poorly written. The examples they provide aren't real-world enough for me to fully understand.

It frightens me that Mozilla should be so lackadaisical about evangelizing these changes. This architecture shift will affect the vast majority of add-ons in one form or another. I verified tonight in a nightly build that both Googlebar Lite and CoLT are affected by this change, the former being broken in a number of areas. It seems to me that Mozilla should shift their evangelism of this new architecture into high gear. Every developer who cares about application compatibility needs to be working on these changes sooner rather than later; otherwise, a ton of add-ons won't work properly come release day.

I have created a GitHub repo storing several Firefox extension utility scripts that I wrote. Here's the rundown on what this repository contains:

compareLocales.pl

Compares all of the locales it finds against a "master" locale (en-US by default) and reports the number of exact duplicate entries for each. This is useful for figuring out which locales have not been updated.

entityToProperty.pl

Converts a given list of locale entities into corresponding properties. Handy for migrating existing entity localizations into a .properties file.

removeLocaleEntries.pl

This script removes a given list of entries from all of the locale folders it finds in the current working directory and below. Useful for cleaning up strings that are no longer needed.

Hopefully others will find these scripts to be useful. I hope to add additional scripts to this repository over time.

The Firebug extension is a very helpful tool for web development. But did you know that you can use its console as an output target for your Firefox extensions? It's pretty simple to do:

Firebug.Console.log("Text to log"); // Output text
Firebug.Console.log(myObj); // Output an object

Is that easy or what? Having this capability is a great way to print out JavaScript objects from your Firefox extensions, making your debugging life much easier.

Adblock Plus is a terrific extension for Firefox, along with the EasyList rule set. One minor problem I've run into recently, however, is that EasyList blocks the automatic package-tracking links that appear in the sidebar in GMail (when viewing emails that contain a tracking number). I found the offending rule in the list and disabled it, allowing me to get my links back. Here's how to do it:

1. Open the Adblock Plus Preferences dialog (Tools » Adblock Plus Preferences)
2. Press Ctrl + F to open the find bar
3. Search for the following text (only one rule should match it): &view=ad
4. Disable said rule

The entire rule looks like this, in case you're curious: ||mail.google.com/mail/*&view=ad

One of the recent updates to Firebug broke a "feature" I used all the time: the ability to select a link with the element inspector, then edit that link's :hover pseudo-class style rules. Well, it turns out that technically, that "feature" was a bug (though I might argue against that fact). In newer versions of Firebug, you have to:

1. Click the element inspector
2. Click the link you're interested in editing
3. Select the :hover pseudo-class menu item in the Style tab's drop-down menu
4. Edit the rule as you like

This new option allows you to "lock" the element in the :hover state, the usefulness of which I can understand. At the same time, it would be great to have an option (perhaps a hidden preference) to bring back the old behavior.

It appears that Microsoft is quietly slipping in a Firefox extension with updates to the .NET framework. The extension is named "Microsoft .NET Framework Assistant" and, based on the description, "Adds ClickOnce support and the ability to report installed .NET versions to the web server." According to reports, this extension:

• Cannot be uninstalled through Firefox
• Changes the Firefox user-agent string
• Does God knows what else

Happily, people have figured out how to uninstall the extension. This move seems pretty dirty to me, but Microsoft has been pointed in this direction for some time now. If you find yourself 'infected' with this piece of malware, do yourself a favor and remove it.

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.

The official 1.0 release of Firebug is now available. If you are a web developer, be sure to pick up this super-ultra-mega-cool extension. You'll thank me later.

I recently stumbled upon what might be the greatest Firefox extension of all time: Firebug. This extension is aimed squarely at web developers and includes a number of mind-blowing features. And I mean mind blowing. Before reading any further, take a look at this short screencast of Firebug in action. Just make sure that you hold on to your socks.

How did I survive this long without this tool? And why haven't we had something like this all along? Firebug single-handedly obsoletes the DOM Inspector extension that ships with Firefox, and nearly obsoletes the mighty fine Web Developer extension that I have relied on for so long. I can now view exactly what my CSS is doing. I can peruse through my page's DOM without opening up the DOM Inspector and switching between windows. I can even edit the CSS and HTML for a page in real time; no reloading necessary! Want to watch your AJAX code in action? Firebug makes it easy.

This tool feels so incredibly polished, and the user interface is so streamlined, that I barely even notice that I have it installed. And it weighs in at an extraordinarily small 288 KB (as of this writing). I cannot say enough good things about this extension; just download it and give it a try. You will not be disappointed.

Beginning with Googlebar Lite 4.0, an interesting problem has cropped up with the search history edit box. Take a look at this screenshot sent in by a Googlebar Lite user:

See how the drop-down marker is all the way to the left of the search box? The actual edit control has been resized to 0, while the popup element (which should be invisible) has been resized. I can get this problem to occur on demand using the Charamel theme. What's most frustrating is that I cannot make it go away. I've tried forcing the edit control's style via CSS, but the rules get ignored. I've built a bare bones toolbar from scratch to try to isolate the problem, to no avail. This is apparently a problem with the autocomplete textbox itself. A Firefox bug? Perhaps. If you happen to run into this problem, there are three courses of action you can take, none of which are very appealing:

1. Use the default theme (if you already aren't). I have yet to see this using the default theme, although my dad has run into it using the default (he uses large fonts in Windows, however, so that might be the difference).
2. Disable search history.
3. Use Googlebar Lite 3.3.

Again, none of these solutions are ideal.

Do you know what's going on here? Know of an existing bug in Bugzilla that references a similar problem? Found a workaround or a fix? Please let me know! I will continue to investigate this issue, but I don't see a fix at this time. If only everything would just work as it is intended to …

A new, major release of Adblock Plus was made available recently. It appears that development of this extension has changed hands (yet again), and that the extension is undergoing a major rewrite. Version 0.6 is incredibly fast and responsive, and the new user interface is light years better than any previous implementation.

What I dislike is the apparent change of the extension GUID. When I installed 0.6, it did not install on top of my existing version. Instead, it showed up as another extension. However, it conveniently alerted me that an old version of Adblock was installed and, after asking me, automatically removed the old release. Awesome!

One of the greatest Firefox extensions of all time, Web Developer, has recently released version 1.0! We're talking good times people. Just check out this change log. The number of updates is incredible. A definite must have for any web developer.