As most of you are already well aware of, Firefox 4 Beta 1 was released a few weeks ago. Beta 2 will follow very soon, and the final version is expected late this year. This relatively long transition period is great for add-on developers, because it gives us plenty of time to update and test our add-ons for Firefox 4. On the other hand, this new major release is going to sport a ton of new features, and it will break a great deal of stuff we need, so it won’t be trivial to upgrade most add-ons to support it. This is the first of many posts that inform add-on developers about Firefox 4 compatibility.
First of all, MDC is your friend: Firefox 4 for developers. This is the document that will and should have all the necessary information for web developers and add-on developers surrounding Firefox 4. Make sure you visit this document regularly and look for changes. If you know of anything missing in that document, please add it yourself or let us know.
Here are some highlights from the document.
The new Add-on Manager object
The nsIExtensionManager interface is no more, along with its RDF backend. Add-on data will now be stored in a SQLite database, and the Add-on Manager is now a JS Module called AddonManager.
A key difference in this new interface is that requesting add-on data is now 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 our startup performance recommendations, you should already be planning on implementing an asynchronous startup process.
There’s a lot going on in this area: XPCOM Changes in Gecko 2.0, and none of your components will work until you adjust to these changes.
Components now need to be explicitly declared in the chrome.manifest file. A number of startup observer topics have been removed, leaving only the one that has always been recommended: profile-after-change. Listeners and category registrations also need to be declared in the manifest and, because of this, some category names have changed.
Changes to tabbrowser
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 to gBrowser.tabContainer.
Remote XUL is going away
Remote XUL is a rarely used feature in Gecko browsers that allow developers to create websites using XUL instead of HTML. Since XUL support is limited to a few browsers, it didn’t make much sense to create websites with it. However, it has been used successfully in a small number of internal business applications (also known as ‘dark matter’).
Remote XUL has been a big maintenance problem, and it 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 anymore. If you’re wondering what happened with XBL 2, removing remote XUL is a necessary step to work towards implementing it.
Theme and UI changes
This is an area where you need to check back frequently, because there are many ambitious plans for the Firefox 4 UI. Whether some of these changes will be implemented or not depends on time and finding the right compromises.
The main document for these UI changes is in the Mozilla wiki: UX Priorities for Firefox 3.7. Some important changes you should know about:
- Tabs on top. There will be a preference that controls the location of the tab strip and toolbars.
- App menu. On Windows (at least?), there will be a single menu button instead of the full menu toolbar. Pressing the Alt key will toggle the “classic” menu. This will surely have an impact on add-ons that overlay menus in the Main Menu.
- Home tab. This is a fixed tab in the first position of the tab strip.
- App tabs. It will be possible to toggle tabs into app tabs, which basically means they can’t be easily closed and their titles will be hidden, only showing the favicon. More interesting changes, like hiding toolbars for these tabs, are being planned.
- There are talks around hiding or completely removing the statusbar, another significant change for add-on developers. The discussion has spanned a number of blog posts, and will surely continue. For more information, please read parts 1, 2 and 3.
- For performance reasons, Firefox 4 is now caching some resources more aggressively, including extension chrome and JS files. This can lead to unexpected behavior when developing an add-on because changes to some files will not apply unless the corresponding cache files are deleted. This is the relevant bug. Please don’t comment on it just to show support for either side; there’s too much of that already. In a nutshell, you should make sure that you have all the right preferences set and you use the -purgecaches command line argument when running your development profile. This will still fail to update your JS Modules, but this should be fixed in a future build.
- User Agent strings are going to be minimized for various reasons. In order to align with these efforts, AMO Editors will soon 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 start removing this code.
- I was informed by a developer that 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.
As you can see, there’s plenty of work to do in order to become compatible with Firefox 4, so this is a good time to begin. However, keep in mind that Firefox 4 is still very much a work in progress, and there are likely more changes to come. Don’t think that you can create a final version of your add-on for Firefox 4 just based on the first beta. My recommendation is that you take your time and make sure you stay up to date with Firefox 4 news.
And, of course, there’s plenty of good stuff coming that will enable you to do amazing things in your add-on, including 2D and 3D animation, multi-threading and interaction with system libraries. Firefox 4 for developers is, again, your friend. The Hacks blog also has a nice overview.
Update: the second installment of this series was published a few days ago.