Firefox 4 Add-ons Compatibility: Time to Get Started

As many of you already know, the first beta of Firefox 4 was released a few weeks ago  . Very soon the second one will follow, and the final version is expected later this year . This relatively long transitional period is beneficial for add-on developers, as it gives us a lot of time to update and test our extensions for Firefox 4. On the other hand, this significant new release will flaunt a ton of new features and break many of the things we need, so that updating most add-ons to support it will not be an easy task. This blog post is one of many that inform developers of compatibility with Firefox 4.

First of all, MDC is your friend: “ Firefox 4 for developers". This is a document that should and will contain all the information needed by web developers and add-on developers who have surrounded Firefox 4. Make sure you visit this document regularly and look for changes in it. If you know of anything missing from this document, let us know.

And here are a few key snippets from this document.

New Add-ons Manager Object

The nsIExtensionManager interface is no longer there, as well as its RDF inside. Add-on information will now be stored in the SQLite database, and the add-on manager will become a JS module called AddonManager .

The key difference with this new interface is that  add-on data requests will now become asynchronous . This also applies to the FUEL library, so every add-on requesting add-on information will be affected by this change. The situation with those add-ons that need to get this data and deal with it during startup will be especially sensitive. However, if you are also trying to follow our recommendations on speeding up boot, then it’s good for you to plan the extension launch process as asynchronous.

XPCOM Registration

A lot is going on in this area: XPCOM will change to Gecko 2.0 , and none of your components will work until you take these changes into account.

Components should now be explicitly declared in the chrome.manifest file. Several boot events have been resolved; the only thing left, the observation of which was always recommended: “profile-after-change”. And observers (listeners) and registration in categories will also need to be indicated in the manifest - and, as a result , some category names have been changed.

Changes to the tabbrowser element

The events TabClose, TabSelect and TabOpen no longer pop up to the level of the tabbrowser element, also known as “gBrowser”. Observers of events (event listeners), tracing these events must now be added to the «gBrowser.tabContainer» object.

Remote XUL is canceled

Remote XUL (remote XUL) is a rarely used feature in Gecko-based browsers that allows developers to create sites using XUL instead of HTML. Since support for the XUL language was limited to several browsers, there wasn’t much point in writing sites on it. However, it has been successfully used in few internal business applications (also metaphorically known as “dark matter”).

Remote XUL was very difficult to maintain, and it was the source of numerous bugs and security issues. For this, the distant XUL will be removed from Firefox 4. Fortunately, HTML 5 already includes a rather abundant box model., so here the main loss for web developers will be the inability to use XBL in the future. If you're curious about what will happen to XBL 2, be aware that removing remote XUL was a necessary step towards implementing XBL 2.

Themes and user interface changes

You will have to frequently inquire about these issues again, as there are many ambitious ideas about Firefox 4 UI. Whether some of these changes will actually be implemented or not depends on whether there is time and if the correct consensus is found.

The main document about these UI changes is the Mozilla wiki: “ UX Priorities for Firefox 3.7 .” Here are some important changes you should be aware of:

• Tabs at the top . A setting appears that controls the position of the tab strip relative to the toolbars.
• Application menu. On Windows (and on other systems?) There will be a single menu button instead of the full menu bar. Pressing the "Alt" key will act as a switch and a switch of the "classic" menu. Which, undoubtedly, will affect the add-ons that are superimposed on the menu in the main menu.
• Home tab. She will always be the first on the tab strip.
• Application Tabs. It will be possible to switch the tab to application mode, which will basically mean that it is more difficult to close such a tab, and its title will be hidden: only the site icon will remain on the spine of the tab. More interesting changes (for example, hiding browser toolbars when such a tab is active) are also planned.
• They also talk about hiding or even removing the status bar, which will also turn out to be a significant change for add-on developers. This discussion has given rise to several blog entries, and it will undoubtedly continue. (You can read more information in its first , second, and third parts.)

Other changes

• To speed up work, Firefox 4 will now be more eager to cache some files, including extension resources - and their chrome, and JS files. This can lead to unexpected behavior when developing add-ons, as changes to some files will not be applied until the corresponding cache files are deleted. And this is the corresponding bug . (Please do not comment on it only in order to support one or another point of view: there are enough of such comments there.) In short, you will have to make sure that you have set all the correct settings and use the “-purgecaches” argument on the command line , when you run the debug profile. And even then, JS modules will not be updated, but it will most likely be fixed in a future Firefox build.
• The lines "User-Agent: ..." will be shortened for various reasons. Acting in line with these changes, AMO editors will also soon track the modification of UA-lines with extensions. We will forbid any unnecessary modifications. Unless your extension has a real need to replace UA, you better remove the corresponding code immediately.
• One of the developers informed me that the URL, thrown on the side panel (the sidebar) , is now the default results in an attempt to open the URL. If your sidebar handles dragging and dropping, then make sure to use “preventDefault” at the same time .

As you can see, there’s a lot of work to be done to be compatible with Firefox 4, so this is a good time to start. However, keep in mind that the development of Firefox 4 continues to a large extent, so further changes are likely to occur. Do not think that you can create the final version of your add-on for Firefox 4, based only on the first beta. I recommend that you take your time and keep up to date with the news about Firefox 4.

And, of course, there will be many good new products that will allow you to do amazing things in your extension - including animation (2D and 3D), multithreading and interaction with system libraries. « Of Firefox 4 developers for » each vdrugoryad you. And the Hacks blog also has a good overview.