A little over a month ago I posted the first compatibility notice for add-on developers. Beta 1 was just out, and there were a lot of important breaking changes that you needed to be aware of. We’re now up to beta 4, RC1 is a couple of months away, and there even more things you should know about.
First, the key documentation:
- Firefox 4 for Developers. This is the definitive document, but it can be a little out of date given that documentation is normally added only after bugs are finalized and somebody from the documentation team picks it up.
- Add-on compatibility for Firefox 4 – time to get started. The first installment in this series of posts. It contains most relevant information up to Beta 1. I’ll try to repeat myself as little as possible in this second part.
- Firefox 4 Compatibility discussion. If you have questions or input regarding Firefox 4 compatibility, this is the best place to discuss it. You can also comment on this blog post, but that’s less visible for other developers.
And now, the new stuff.
New UI Features
Beta 4 shipped with a new feature called Firefox Panorama (previously 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. I’ve been told that the changes to the tab code are minimal, but I know that at least Tree Style Tab (a personal favorite) is broken since beta 4. There’s a new button in the tab bar that triggers Panorama, and also a context menu option.
Details about the Firefox App button. If you have an add-on that relies on the main menu, keep in mind that the classic menu can still be toggled with the Alt key, but most of the time you’ll only see the App button (on Windows, at least). I’ve been told that the new place to overlay your menus in this menu will be under the Exit menu item. That doesn’t sound right at all, so it’s possible it will change in the future.
Toolbar buttons are being handled very differently and have different dimensions. Since this essentially breaks most add-ons, there’s some ongoing discussion about it. The new designs require you to create only the inner part of the button, and let CSS generate the border, background and padding around it. You can use CSS to override this behavior, as usual. These are the current icon sets for the 3 major platforms: Windows, Mac and Linux. They should give you a good idea of the new icon dimensions and states. The icons for Linux are pretty much the same as before, as it seems that Firefox is (for the moment, at least) still relying on standard Gnome icons to populate the toolbar.
Development and Packaging
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.
If you edit your add-on files directly in your development profile folder in order to test changes quickly, you may find yourself wondering why the changes aren’t being picked up by Firefox 4 the same way as before. What’s happening is that Firefox 4 is now caching certain code files more aggressively now, and a couple of bugs were introduced in this code. Bug 531886 and bug 520309 are the key bugs here. The proposed solution is that there will be a command-line option to disable the cache and allow developers to continue working this way, but that still won’t work for all file types until bug 531886 is fixed.
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 that reading them independently from the filesystem, so keeping as many files as possible packaged together is a performance win, specially on mobile. The same idea is being extended to add-ons, and the work being done in bug 533038 will add a new feature that add-ons can opt-in to in order to load more efficiently. The idea is that you will be able to include a new tag in install.rdf that indicates that your add-on can be installed without extracting the files from the XPI. This will depend on the file types that can be read from the package, so for the moment it’s unlikely that add-ons with binary components will be able to opt-in, and themes may have some limitations due to their preview images. It’s also recommended that you move away from the usually recommended practice of packaging all chrome files in a JAR. None of this is part of Firefox 4 yet, so it’s still malleable, but it will appear in upcoming betas.
Also coming in future releases, a new profile manager. Bug 539524 is tracking this new development, and it seems that the new tool will work independently from Firefox, will have more interesting features, but will also lack the UI we’ve grown accustomed to. 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 unless there’s a suitable replacement.
The old and deprecated nsIPref interface has been removed. This shouldn’t affect anybody using the recommended nsIPrefService or the FUEL library. Thanks to Matthew Wilson for the catch.
If your XPCOM component reads input data from the command line, this registration will now need to happen through chrome.manifest. However, the documentation still doesn’t specify how to do this. Thanks to Jason Barnabe for the notice.
There’s surely more coming up, and if I’ve missed something, please let me know. There will be a least on more post in this series, after the trunk goes through “feature freeze” and Firefox 4 begins to feel like the real deal.
Remember: if your add-on is already compatible with the latest beta but your install.rdf file isn’t up to date, you can go to the Files and Versions section of your add-on in the Developer Hub and update the compatibility info. No need to upload a new file!