Compatibility of add-ons with Firefox 4: time to start

As many of you are already well aware of, the first beta of Firefox 4 was released a few weeks ago. Very soon it will be followed by the second one, and the final version is expected later this year . This relatively long transition period benefits developers of add-ons, as it gives us a lot of time to update and check our extensions for Firefox 4. On the other hand, this new significant release will flaunt a lot of new features, and break many of the things we need. that updating most add-ons to support it will not be an easy task. This blog post is one of many knowledgeable developers about 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 are aware of anything missing in this document - let us know.

And here are a few key pieces from this document.
')

New add-on manager object

The nsIExtensionManager interface is no longer there, as is its RDF backside. 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 of this new interface is that the add-on data requests will now become asynchronous . This also applies to the FUEL library, so every addition that requests information about the additions will affect this change. The situation with those additions that need to obtain this data and deal with them during the launch will be especially delicate. However, if you are also trying to follow our recommendations on speeding up the initial load , then you should have a good idea to plan the process of launching the extension as asynchronous.

XPCOM Registration

A lot happens 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. Multiple boot events eliminated; the only thing left, the observation of which has always been recommended: "profile-after-change". And observers (listeners) and registration in categories will also need to be specified in the manifest - and, as a result , some category names are changed.

Changes to the tabbrowser element

The TabClose, TabSelect, and TabOpen events no longer pop up to the level of the tabbrowser element, also known as “gBrowser”. Event listeners that track these events should 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 allowed developers to create websites using XUL instead of HTML. Since support for the XUL language was limited to several browsers, there was little point in writing websites on it. However, it was successfully used in a few internal business applications (also metaphorically known as “dark matter”).

Remote XUL was very difficult to maintain, moreover, it was the source of numerous bugs and security problems. For this, remote XUL will be removed from Firefox 4. Fortunately, HTML 5 already includes a fairly abundant box model , so that the main loss for web developers will be the inability to use XBL in the future. If you're wondering what will happen with XBL 2, know: eliminating a remote XUL was a necessary step towards implementing XBL 2.

Theme and user interface changes

On these issues you will have to frequently and re-inquire, since there are many ambitious plans about Firefox 4 UI. Whether some of these changes will actually be realized or not depends on whether there is time and whether 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 bar relative to the toolbars.
• Application menu. On Windows (and on other systems?) There will be a single menu button instead of a full menu bar. Pressing the "Alt" key will act as a switch and a switch for the "classic" menu. That, of course, will affect the additions that are imposed on the menu in the main menu.
• Home tab. She will always be first on the tab bar.
• Application tabs. It will be possible to switch a tab to the application mode, which will basically mean that such a tab is more difficult to close, and its title will be hidden: on the spine, the tab will only have a site icon. More interesting changes (for example, hiding browser toolbars when such a tab is active) are also planned.
• They also talk about whether to hide or even remove the status bar altogether, which also turns out to be a significant change for add-on developers. This discussion has spawned several blog entries, and it will certainly continue. (You can read more information in its first , second and third parts.)

Other changes

• To speed up Firefox 4, it will henceforth be more avidly to cache some files, including extension resources - both chrome and JS files. This can lead to unexpected behavior in the development of add-ons, since 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 it only to support this or that point of view: there are plenty of such comments.) In short, you will have to make sure that all the correct settings have been set and that the command line argument “-purgecaches” is used, when you run a debug profile. And even then the JS-modules will not be updated, but this will most likely be fixed in the future Firefox build.
• The lines "User-Agent: ..." will be shortened for various reasons. Acting on these changes, the AMO editors will also soon be tracking extensions to UA-strings . We will forbid any unnecessary modifications. Unless your extension has a valid need to replace the UA, you better remove the corresponding code immediately.
• One of the developers informed me that the URL thrown on the sidebar (sidebar) , now by default leads to an attempt to open this URL. If your sidebar handles pulling and throwing, then make sure that you also use preventDefault.

As you can see, there is a lot of work to be done to achieve compatibility with Firefox 4, so now is a good time to start it. However, keep in mind that the development of Firefox 4 largely continues it, so that 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 the time to get up-to-date on the latest Firefox 4 news.

And, of course, there will be many good new products that will allow you to do amazing things in your expansion - including animation (2D and 3D), multithreading and interaction with system libraries. " Firefox 4 for developers " suddenly order a friend for you. And the Hacks blog is also a good review.