“I want to upgrade Firefox, but my add-ons won’t be compatible.”
This makes me sad. And it’s a problem that’s been magnified by the switch to rapid release. One of the strengths of Firefox is it’s rich selection of add-ons. In fact, 85% of Firefox users have chosen to install an add-on. On average, those users have 5 add-ons installed. Firefox users really love their add-ons. So it’s not surprising that they get frustrated when one of their favorite add-ons gets disabled because it’s not marked as being compatible with the new Firefox update they just installed.
So I started working on a project to fix it. The end result will be that most add-ons will automatically be compatible with Firefox, starting with (hopefully) Firefox 10.
At the time of writing this, I’ve not yet finished the project. There are parts described below that I haven’t completed yet. But it’s progressed far enough to safely enable the new behavior on Nightly builds, starting with today’s Nightly build (labelled 2011-11-18).
Many of the changes are also on Aurora, but disabled. If you want to test the new behavior, go into about:config and change the
extensions.strictCompatibility preference to
true to re-enable the old compatibility behavior). Once I have a couple more major bugs fixed, we’ll make the call on whether to enable the new behavior by default on Aurora (which will ultimately become Firefox 10).
How does this work? The gritty details.
The problem with incompatible add-ons is that most of them are actually compatible – they just don’t know it. Unfortunately, blindly enabling all add-ons will enable some that are really are just incompatible, which will end in something breaking. So we needed a way to detect which add-ons would most likely be affected by incompatible changes to new versions of Firefox.
extensions.strictCompatibility preference is set to
false, add-ons will use the new compatible-by-default behavior. However, there are several reasons the Add-ons Manager will revert to using the old method of strict compatibility checking for a given add-on:
- The add-on author chose to opt-in to strict compatibility checking by adding
<em:strictCompatibility>true</em:strictCompatibility>to the add-on’s install.rdf
- The add-on has been tested and determined to not be compatible with that version of Firefox (the Add-ons Manager gets this information from AMO)
- The add-on uses a binary component
- The add-on hasn’t been updated in an extremely long time (the compatibility data needs to state that it is at least compatible with Firefox 4, or Toolkit 2.0)
- The add-on declares that is it only compatible with future versions of Firefox (we assume that add-ons are not backwards-compatible)
In the future, we also hope to give Firefox the ability to do a series self-tests to determine whether an add-on has broken something, and automatically mark that add-on as incompatible. Additionally, if the above heuristics end up producing false-positives, we may add the ability for AMO to tell the Add-ons Manager that it’s heuristics are wrong for a given add-on.
This also required a change to the way add-on updates are handled. Previously, users that disabled add-on compatibility checking didn’t get updated to the most recent version of their incompatible add-ons, since those updates often weren’t compatible with their version of Firefox (even thought they explicitly disabled compatibility checking). This meant that those users (which included most users running Nightly builds) didn’t automatically get important security updates of all their add-ons. The changes needed for the compatible-by-default behavior made it easy to support updating incompatible add-ons even for users that disabled compatibility checking, which means they’ll be running a more up-to-date and secure browser.
Finally, I should note that making add-ons compatible by default does not mean that add-on authors should stop including compatibility data, or stop updating it. Older versions of Firefox still rely on the compatibility data, and users can choose to opt-in to strict compatibility checking. Furthermore, add-ons need to still declare compatibility with at least Firefox 4 (or Toolkit 2.0).
Gmail Archive Ukraine translation here – http://www.stoodio.org/archive-solving-firefoxs-add-on-compatibility-problem.