This article offers details on changes in Firefox 4 that may impact existing extensions.
The status bar has been removed from Firefox 4, with a new add-on bar added in its place. See The add-on bar for details.
If your add-on creates a new toolbar using an overlay, your toolbar may not show up. This happens when your
<toolbox> element overlay is a child of the
<window> element instead of a direct child of the overlay element. Move the toolbox out of the window element to fix this problem.
On Windows, the menu bar is now hidden by default. Instead, there's a single button that opens a simplified Firefox application menu. This menu includes the most used menu features, which makes the application easier to use. The menu bar can still be accessed by pressing the Alt key.
If your add-on is discoverable only through the menu bar, you'll want to overlay the application menu as well. There isn't a specific place to put extension menu items, so you should take a look at the menu and select the right place for your particular extension.
A number of changes were made to the
<tabbrowser> element to help support app tabs and Panoramas, as well as to make the tab bar into a standard toolbar. Other changes that may break existing extensions include:
TabOpenevents no longer bubble up to the
gBrowser). Event listeners for those events should be added to
gBrowser.tabContainerrather than to
- The tab context menu is no longer an anonymous child of the
gBrowser.tabContextMenu. See this blog post for more details.
Several changes have been made that affect add-ons and applications that include XPCOM components. See XPCOM changes in Gecko 2 for details.
The overhauled Add-on Manager is implemented as a tab instead of in a separate window. Among the changes that affect your browser from a user experience perspective is that your add-on's icon can be 64x64 pixels now instead of 32x32. While 32x32 pixel icons still work, obviously your add-on will look better if it provides a 64x64 pixel icon instead. Fortunately, 64x64 icons are backward compatible and scale down well, so you can just switch instead of needing both sizes.
In addition, the back-end of the Add-on Manager was redesigned. The
A key difference with the new API is that requesting add-on metadata is now asynchronous instead of synchronous; this applies to add-ons using FUEL as well, so all add-ons that request metadata about add-ons will need to be updated.
ChromeWorker will be improved to fill the void.
The API for handling network redirects has been changed to be asynchronous; any add-ons registering in the "net-channel-event-sinks" category will need to be updated to use the new API
Firefox 4 no longer extracts XPIs when installing extensions. It just places the XPI file in the user profile, and then reads the chrome files and others directly out of the XPI. A jar inside the XPI still works, but is no longer necessary, so that can make your development or build easier. This was done mainly for performance reasons on slow OSes, and allows better cache invalidation, which also helps developers. However, not all kinds of files can be read from within the XPI yet, so if your extension uses one of those, you need to specify
<em:unpack> in your install.rdf to cause Firefox to still extract your XPI and use single files, otherwise your extension will fail when trying to access these files.
If your extension only contains these types of files then you do not need to make any changes:
- default preferences
If your extension contains any of the following then you will need to include
<em:unpack> in the install.rdf:
- Binary XPCOM components
- Shared libraries loaded with ctypes
searchplugins/(which are supposed to be loaded automatically by Firefox)
- Window icons (might get fixed)
If your extension code accesses other files that you have packaged in the XPI then you will either need to include
<em:unpack> in the install.rdf or you may be able to support packed installation by making some changes to your code. Any code that used getInstallLocation() and nsIFile will either need em:unpack or needs to be changed. You can use the method
Addon.getResourceURI(), it will return an
nsIURI pointing to the requested file. If the extension is unpacked then it will be a
file:// URI. If the extension is packed then it will be a
jar:// URI. You can open streams to these URIs by opening a channel using the
nsIIOService which will allow you to load the files contents without any unpacking.
This should only affect a very small number of developers. In previous versions of Firefox, child
HWNDs were created on Windows for internal use. As a part of the work toward improving graphics performance, these are no longer created.
Unfortunately, a few extensions have been getting access to these
HWNDs and manipulating them directly; these extensions will no longer work in Firefox 4. We have put a few hacks in place to help certain pointing-device drivers and assistive technology software (screen readers, for example). However, we have decided against adding even more hacks to support extensions, which should never have been doing this in the first place.
If you maintain an extension that uses native components that rely on
HWNDs that no longer exist, you'll need to update your extension. There are two ways to do this.
The first, and better, solution is to stop accessing
HWNDs and instead use Web features or XUL to implement your extension. There are a lot of new features in Firefox 4 that make possible a lot of things that used to require native code, so you may no longer need to do this.
If you find that this doesn't work, and you still need to directly access
HWNDs, you may find that your only solution is to write an NPAPI plugin that does the work. This may be a lot of work, but it should work. Of course, this may not help you if the specific
HWNDs you were using no longer exist.
Because Firefox now caches code and other resources more aggressively, you'll want to be sure to purge the caches when you start up Firefox 4. Otherwise you may be testing obsolete pieces of your add-on. To do this, run Firefox with the
-purgecaches command line option.
The old Profile Manager tool will be getting removed from Firefox 4, although it hasn't been yet. This tool hasn't been updated for a long time and is missing features. On top of that, its presence is slowing down application startup.
-install-global-theme command line options have been removed. Handling global installation has always been complicated, and discussions are in progress as to how to address the subject going forward. In the meantime, see Installing extensions for information on ways to automatically install add-ons.
- Making Your Add-on Compatible with Firefox 4 (blog post)