Towards the end of last year, the need for a faster Firefox release cycle was apparent, and nearly every team at Mozilla began preparing for the major changes afoot. Add-on compatibility has always been a huge barrier to releasing more often, so it was critical we have a plan that wouldn’t leave add-ons or users behind. With previous releases usually a year or more apart, we could begin compatibility outreach to developers 3 months in advance of the release, and were able to get at least 80% of the most-used Mozilla-hosted add-ons compatible with the new version. For this new system to work, we wanted a compatibility process that didn’t require developers to lift a finger unless their add-on was one of the few broken.
Firefox assumes that add-ons are incompatible from one version to the next because, in previous versions, they often were. This becomes a big problem when nearly all add-ons actually are compatible in our shorter release cycles. We devised a plan to work around the assumed incompatibility that had three parts:
- Firefox developers should consider the add-on compatibility impact of every change they make
- Firefox developers should follow a compatibility notification process to ensure we communicate changes to add-on developers
- AMO (addons.mozilla.org) will scan hosted add-ons for issues with the new Firefox version and automatically bump their compatibility if none are found
Longer term, the Add-on SDK lets developers build restartless add-ons without worrying about compatibility hassles.
How’s it working out?
Compatibility-breaking changes in Firefox have been minimal in the first four 6-week development cycles, with the exception of two larger changes that were reverted because of their larger impact. Jorge has posted detailed guides to changes that affect add-on developers for each of those releases (5 & 6, 7, 8), and Firefox developers are often coming to us to discuss the impact of their changes on add-ons.
We’ve automatically bumped thousands of add-ons for each Aurora version and emailed developers with the results of our compatibility scanning. When Firefox 6 launched, 97% of add-ons compatible with Firefox 5 were still compatible with 6. And we’re on track to launch Firefox 7 tomorrow with 99% compatibility from 6.
But with all of that, why do we still see users reporting that their add-ons aren’t compatible?
Our compatibility plan has two notable shortcomings: it doesn’t work for add-ons with binary components and it doesn’t work for add-ons not hosted on AMO. The vast majority of add-ons don’t contain binary components, which must be recompiled with every version of Firefox in order to continue working. And while we know a lot about add-ons that are hosted on AMO, we didn’t know much about the other add-ons in Firefox’s ecosystem.
In Firefox 4, as a result of enriched metadata in the Add-ons Manager, we have a much better idea of what add-ons are out there in the wild. And it was quite eye-opening when I learned that only 25% of the 600 million add-ons in use every day in Firefox 4 and later are active on AMO. That means at least 75% of add-ons aren’t getting the benefits of the automatic compatibility system we created, as well as the security and quality reviews that hosted add-ons receive. When we created the compatibility plan for the new development cycles, we weren’t aware that so many add-ons wouldn’t even be affected by it.
So, how do 450 million add-ons get installed if not from AMO? Third-party bundling. More and more software tries to plop a toolbar into Firefox when you install it, often without asking you. Java Console alone has more than 100 million installations among Firefox users on Windows, and it doesn’t even do anything. While some of these add-ons are keeping up with our release compatibility, many use their own update mechanisms instead of the built-in update service that works with Firefox’s compatibility checking, so in order to get a compatible add-on, you must update the third party software separately.
When these add-ons aren’t compatible with a new version of Firefox, it’s an even bigger problem because it’s often confusing to users as to what functionality they provide. When they’re told that Skype or their antivirus toolbar isn’t compatible with the new version, they may think upgrading means they can’t use Skype at all or that their computer will be more susceptible to viruses.
Firefox 8 (in beta later this week) tries to curb some of this behavior by requiring users to opt in to new add-ons and letting users disable add-ons they’ve already acquired.
Help is on the way
We’ve been working on a plan for fixing add-on compatibility that also takes non-hosted add-ons into account. Instead of working around Firefox’s assumption that add-ons are incompatible between versions, we’re going to teach Firefox to be a bit more trusting of add-on compatibility with new versions. You can read more about the idea on its feature page, and I’ll post more about this change on the Add-ons Blog when it’s underway.
In the meantime, if you find that your add-ons aren’t compatible, install the Add-on Compatibility Reporter and try ’em out — there’s a good chance they work fine.