Archive for the 'Extensions' Category

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.

Googlebar Lite 4.6.3 fixes two regressions:

• Bug Fix: An uncaught exception in the new URL parsing logic (added in 4.6.2) was causing the URL bar in Firefox to act incorrectly when a new tab was opened.
• Bug Fix: The new URL parsing was too strict. Because of this, search terms were not being updated appropriately on non-web searches (image searches, group searches, etc.).

Googlebar Lite 4.6.2 has been posted over at Born Geek. Changes in this release:

• The “Google GMail” option in the Googlebar Lite main menu now points to the secure https:// address.
• Bug Fix: Searching country-specific pages often caused search terms to become corrupted in the Googlebar Lite search box. The URL parsing logic has been rewritten and should now work as expected.
• Bug Fix: Some translational errors in the Dutch (nl-NL) locale have been fixed.

I failed to mention yesterday that a new build of Googlebar Lite is now available. This new release fixes two small bugs:

• Fixed a problem with highlighting on pages that contain frames.
• Fixed a strict JavaScript parsing error.

A brand new version of CoLT is now available to download. Here’s what’s new in this release:

• CoLT now supports an unlimited number of custom formats for the ‘Copy Link Text and Location’ action.
• When only one format is available for the ‘Copy Link Text and Location’ action, it appears as a menu item, rather than an item in a sub-menu.
• Custom menu separators can now be added to the ‘Copy Link Text and Location’ sub-menu.
• Added a new Czech (cs-CZ) translation.
• Added a new Korean (ko-KR) translation.
• Added a new Lithuanian (lt-LT) translation.
• Added a new Chinese Simplified (zh-CN) translation.

The next release of CoLT, which I previewed recently, has been sent to the translators for localization. So far, I’ve gotten back 7 out of the 14 languages that are supported; hopefully, the others will roll in soon. An additional 3 localizations are also in the works (Czech, Korean, and Chinese Simplified). With any luck, the new version will be available by the end of the month (this translation step usually takes a while).

The next version of CoLT is under development, and more importantly, nearly complete. Since a picture is worth a thousand words, below is a screenshot of what I’ve put most of my effort into:

As you can see, CoLT 2.3 will allow users to have as many custom formats for the “Copy Both Link Text and Location” action. This should make many people happy, based on the number of requests I’ve gotten for this feature. One other improvement is the ability to have menu separators in the “Copy Both” popup menu. That should make things a little nicer on an organizational level.

This new system for custom formats also provides one other benefit. When only one custom format is available, I now show a single menu item in the context menu, rather than the standard sub-menu. A number of people apparently only use one custom format choice today, and they dislike the fact that the one item lives in a sub-menu (they would rather it live one level up). CoLT 2.3 will bring this wanted feature to reality.

There are a few things I still need to polish up before I send it to the translators to be translated (the final step before a release). First, I need to figure out how (or even if) the old custom format data will be migrated to this new system. Second, there is a strange XUL bug lurking in the listbox element that I’m using. When no child elements appear in the box initially, and a new child is added, the box is resized vertically, subsequently pushing the OK and Cancel buttons in the dialog box out of view. This makes those buttons inaccessible, which is clearly a bad thing. Granted, this is an edge case, but it needs to be handled somehow.

Stay tuned for further updates on this new version. I’m excited about this release, as it should please a number of people who have been patiently waiting for these new features.