How To Make Any Firefox Add-on Compatible with All Versions

Feel free to test all other Nightly Tester Tools features and let us know how you like them in a comment below!

Making your add-on compatible with Firefox 4

Nov112010

Firefox 4 beta 7 is out, and now is the best time to evaluate your add-on's compatibility with the next major Firefox release. This is the first "feature frozen" release, meaning that there will be no more major changes performed to the UI, APIs or features in Firefox. Other than bug fixes and stability improvements, this the Firefox that will make it to the public, and you should be able to upgrade your add-on to work for this beta without having to worry about something being broken in the following betas and release candidates. Firefox 4 is coming! If you want your add-on to be compatible, the time is now.

How can you keep track of releases? One way is to download the latest beta and check for updates regularly. New versions are normally being released every few weeks. You can also visit theReleases page regularly. Finally, you can follow the Mozilla blogand keep up with Firefox news.

In this blog post I'm going to cover all breaking changes introduced in Firefox 4 that I'm aware of, including the ones I mentioned on my previous 2 posts (Part 1, Part 2). Firefox 4 is the largest release so far in terms of code and API changes, so there's likely something on this list that affects your add-ons. This list is as thorough as I could manage to make; my objective is to make it as easy as possible for you to update your add-on so your users won't have a hard time deciding if they should update their Firefox or not.

Add-on Packaging and Development Environment

In order to improve Firefox performance, a lot of work is being done to improve file loading and processing at startup. This includes add-on files as well, so there are a couple of changes that concern us.

Packed extensions

Firefox 4 will ship with most code files packaged in a single JAR file, also referred to as Omnijar. Reading files from a package is generally much more efficient than reading them independently from the filesystem, so keeping as many files as possible packaged together is a performance win, specially on mobile platforms. The same idea is now extended to add-ons, and by default they will be installed in the profile folder without unpacking them. There are some consequences to this:

Some add-ons will not work without unpacking, notably add-ons with binary components or other libraries. This also affects dictionaries and add-ons that include search plugins or window icons. Those add-ons that need to be unpacked must add an unpack flag to their install.rdf manifest.
If you read any files that are contained in your XPI from the profile dir, this won't work anymore. You can extract them using the chrome protocol or the nsIZipReader component, or find other ways to generate them. You can also use the unpack flag if nothing else works.
You can still have you working directory in your profile as you did before. The extension loader will check for either the XPI package or the unpacked directory. However, for the final build you should aim to have your add-on installed without unpacking.
It's also recommended that you move away from the previously recommended practice of packaging all chrome files in a JAR. Since the XPI is not unpacked anymore, having the JAR (a package within a package) only adds overhead.

Caching

Firefox is now caching code and other resources more aggressively. To make sure that your development profile is always picking up the changes, you should run Firefox 4 with the -purgecaches command line option. This will clear all relevant caches, to make sure you're running the latest code.

The Profile Manager

The Profile Manager tool we've grown accustomed to is being taken out of Firefox. There's a long discussion surrounding the reasoning behind this decision. In a nutshell, the profile manager hasn't been updated for a very long time and is lacking in features, on top of some of its code causing slowdowns at startup. Needless to say, it won't be removed without a suitable replacement. Bug 539524 is tracking this new development. The new tool will work independently from Firefox, kind of like a launcher script, and is meant to be more robust than its predecessor. Since this tool is not bound to the Firefox 4 release timeline, it could be finished afterFirefox 4. You can always use the Firefox 3.6 Profile Manager in the meantime, of course.

Global extension installation

The -install-global-extension and -install-global-theme command line options have been removed. Global installation has always been a tricky subject, but there will surely be discussions in the future on how to move this forward while respecting users. For alternatives on how to automatically install add-ons, read this documentation at MDC.

XPCOM

XPCOM Registration

Components now need to be explicitly declared in thechrome.manifest file. This includes binary components as well. A number of startup observer topics have been removed, leaving only one: profile-after-change. Listeners and category registrations also need to be declared in the manifest and, because of this, some category names have changed. More details at MDC:XPCOM Changes in Gecko 2.0.

xpcnativewrappers=no is going away. This practice has always been considered unsafe, and there are safer alternatives for it.

The new Gecko SDK is still not available at the MDC page. Developers that use binary XPCOM have to build it themselves from source. The source code for beta releases is available at theFTP site.

The old and deprecated nsIPref interface has been removed. This shouldn't affect anybody using the recommended nsIPrefService or the FUEL library.

UI

Toolbars

Toolbar buttons have different dimensions. Here are the current icon sets for the major platforms:

Windows. Icons are 18 x 18 px. They have a very simple style and appear to be same for Aero and non-Aero.
Mac OS X. Icons are 20 x 20 px. Simple style as usual, but this time around the icons don't include the surrounding button style, making them more consistent with other platforms.
Linux. Icons are 24 x 24 px. As usual, the theme relies mostly on Gnome icons.

This is a radical departure from the 3.6 icons. Only Linux retains the same icons and icon sizes, so you'll need to create new toolbar icons for Firefox 4 unless you want to deal with scaling (you don't). Fortunately, the chrome manifest file allows you use someconvenient flags that allow you to easily separate skins depending on OS and application versions.

Also, if your add-on creates a new toolbar with an overlay, you may find that your toolbar is not showing up. This happens when your toolbox element overlay is a child of the window element, instead of a direct child of the overlay element. Moving the node out fixes the problem.

The Firefox App Menu

The main menu (File, Edit, View, etc.) is now hidden by default for Firefox 4 on Windows. Instead, there's a single button that opens a simplified Firefox App Menu. This menu includes the most used menu features, making users' lives easier. The "classic" menu can still be toggled using the Alt key.

If your add-on is only discoverable through the main menu, you'll want to overlay the app menu as well. There's no exclusive spot for extension menu items, so you should study the menu and identify the best one for yours, and then find the right ids for your overlay.

The Statusbar

It's gone. It has been replaced with the Add-on Bar.

By default, there will be no more chrome at the bottom of the browser window. If an add-on adds an icon or something else to the Add-on Bar, it will appear in the same location and with a similar style as the current statusbar. The Add-on Bar has the advantage that it is a proper toolbar, and it may allow user customization in the future (but not in Firefox 4?). It has the disadvantage of being turned off by default, and also being thicker, meaning that users will not be very welcoming of add-ons that add stuff down there.

For backward compatibility, the old statusbar is now completely contained in the Add-on Bar. So, if your add-on overlays the statusbar, it will continue to work. This is only a transitory solution, so you should look into moving your buttons out of the statusbar and into the Add-on Bar as soon as possible.

Tabs

Beta 4 shipped with a new feature called Firefox Panorama(formerly known as Tab Candy). This is a major new feature and a new way to look at and manage tabs in Firefox. Unfortunately this also means that some tab manager add-ons may break due to the changes introduced in the Firefox tab code. There's a new button in the tab bar that triggers Panorama, and also a tab context menu option.

Tabs appear on top by default. There is a preference that controls the location of the tab strip and toolbars.

App tabs. It is now possible to toggle tabs into app tabs, which basically means they can't be easily closed and their titles are hidden, only showing the favicon.

The Add-on Manager

Firefox 4 has an overhauled Add-on Manager, no longer opening as a separate window but as a new tab. There's much more room for add-on information, and the space for your add-on icon is now 64 x 64 px. The old 32 x 32 px icons still look OK (they are not scaled), but you'll probably want to upgrade. Scaling down to 32 x 32 is not too bad, so you can include the larger icon without having to worry too much about backward compatibility.

The Add-on Manager backend was also overhauled. The nsIExtensionManager interface is no more, along with its RDF storage. Add-on metadata is now stored in a SQLite database, and the Add-on Manager is now a JS Module named AddonManager. A key difference in this new interface is that requesting add-on metadata is asynchronous. This applies to the FUEL library as well, so every add-on that requests add-on data is affected. This is particularly delicate for add-ons that have to fetch and deal with this data at startup. However, if you're also trying to follow ourstartup performance recommendations, you should already be planning on implementing an asynchronous startup process anyway.

XUL and Overlays

The DOM surrounding the tabs and their internal browser elements has changed to allow easier overlaying. However, this means that if your code browses the DOM using parentNode, like to get access to the associated notificationbox of a tab, you may find that this code no longer works. This is something you shouldn't be doing anyway, since the gBrowser object and its related objects have convenient methods to access these nodes.

The TabClose, TabSelect and TabOpen events no longer bubble up to the tabbrowser element, also known as gBrowser. Event listeners for these events should be added togBrowser.tabContainer.

Remote XUL

Remote XUL is a rarely used feature in Gecko browsers that allow developers to create websites using XUL and XBL instead of (or along with) HTML. Since XUL support is limited to a few browsers, it never made much sense to create websites with it. However, it has been used successfully on a number of internal business applications (also known as "XUL dark matter"), and even some public websites.

Remote XUL has been a big maintenance problem, and has been the source for numerous bugs and security problems. For this,remote XUL will be removed in Firefox 4. Luckily, HTML 5 already includes a fairly robust box model, so the main loss here is that web developers will not be able to use XBL on webpages anymore. This also means that inserting XUL into (remote) HTML pages will not be possible anymore, not even for add-ons in some cases. If the code is loaded from a chrome URL, like in an iframe or an XBL binding, this should continue to work.

In a nutshell, XUL content from remote sites of even the local file:// protocol won't load. Not all is lost, however. To enable a transition period from XUL to something else, remote XUL support hasn't been entirely removed, only disabled. There's a whitelist where individual domains can be added in order to enable XUL and XBL on them. This whitelist is not accessible from the UI, though, so I've created the Remote XUL Manageradd-on to fill this gap. You should be able to easily manage the whitelist with this add-on.

Other

JS objects can no longer be passed between threads, making the Thread Manager object fairly useless for add-on developers. This is a last minute fix that will hopefully affect just a few developers, but it will have a high impact because there are few alternatives available at the moment. There are discussions about improving the ChromeWorker interface so that it becomes a suitable replacement, but it remains to be seen if this will happen in the coming betas.
User Agent strings have been minimized for privacy reasons. In order to align with these efforts, AMO Editors will be looking for UA manipulation in extensions. We will forbid any unnecessary modifications. Unless your add-on really needs to change the UA, you should remove this code.
There's one bug that affects theme developers on Windows, and causes a black box to appear near the titlebar. There are a few workarounds explained in this Mozillazine thread.
JSON Strings with trailing commas are no longer accepted by the SpiderMonkey JSON parser.
The network redirects API has changed to be asynchronous now. This affects any extension registering in the "net-channel-event-sinks" category, breaking all redirects.
Dropping a URL into the sidebar now has the default behavior of trying to open this URL. If you handle drag and drop in your sidebar, make sure you use preventDefault.
Firefox 4 will support the 32 and 64-bit Intel architectures on Mac, and has dropped PPC support. List of supported platforms.

Documentation and Help

We're trying to publish as much documentation about Firefox 4 as possible in order to help add-on developers get everything right the first time. The Firefox 4 for Developers article is the official source for everything that's new in Firefox 4, including breaking API changes. There are, however, many things included in this post that are not included in the article. I tried to cover everything I'm aware of, and if anything else changes or is discovered during the release process, it will be documented in this blog.

If there's anything you think I've overlooked, or you want to discuss about Firefox 4 compatibility, this thread in the Add-ons Forum is the best place to go. You can also join our #extdev IRC channel for one-on-one live help. I usually hang out on that channel, but there are also lots of other experienced developers willing to help. Just join the channel and ask your question.

Finally, if you have a featured add-on, or you want your add-on to qualify to be featured on AMO, you should take into consideration that after Firefox 4 RC1 is released, add-ons must be compatible with the latest release in order to qualify. RC1 is scheduled for January 2011, so make your plans accordingly.

Happy coding!

Dreamboy

2011年6月26日星期日