Solving Firefox’s add-on compatibility problem
“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 false (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.
Assuming the 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 – www.stoodio.org/archive-solving-firefoxs-add-on-compatibility-problem.
20 thoughts on “Solving Firefox’s add-on compatibility problem”
Great stuff!
Blair, is there any reason why not to harness crowd power usin the great Add-on Compatibility Reporter? I’ve thought the report is being used precisely for this kind of purpose.
I certainly want to explore some kind of reporter functionality in the future (I haven’t had time yet), but I don’t think Add-on Compatibility Reporter would fit in as-is.
There’s a bug on file to change it’s interface to better match the new way compatibility works. That will be fine for the add-on, but it needs some re-thinking to make it more useful/consumable to non-testers. One thing I’d like to try is to submit the results of the self-tests to AMO/Socorro (the crash-reporter database/analyzer).
@Funton
At least the developer of BetterPrivacy complained that the reports he gets via the compatibility reporter are rather unreliable. For instance, a version which he *knew* was broken for a certain BetterPrivacy/Firefox combination was marked as compatible nonetheless by many users.
extensions.strictCompatibility preference is set to false,no risk ?
There shouldn’t be any risk – but it’s still being tested, and it is possible an incompatible extension will be enabled. Set to true if you want the old behaviour that will only enable extensions that explicitly say they’re compatible.
This is a giant step forward!
Folks running the Add-on Compatibility Reporter need to do this to test:
1. In Add-ons manager – extensions, click the “Enable” compatibility checking link at the top,
2. Disable the Add-on Compatibility Reporter to prevent it from disabling compatibility checking at the next startup.
I tried your method but i got better results by adding nightly tester and then going to about:config and changing nightly.testcheckcompatibility from false to true and then adding firefox addon check compatibility 1.3 I have 57 addons and they all work know with the exception of mcafee site adviser
Steffen’s steps are alright, especially #2. However, since ACR currently has issues and its main function is now performed through the new preference, I rather:
* Back up critical profile settings (bookmarks & passwords; I can reconfigure the rest)
* Erase current profile (files included) and create a new one (empty)
* Set extensions.strictCompatibility to false
* Install my previous addon set, except ACR (only casualties: Graphing Calculator Toolbar, Leet Key. Why!?)
* Restore bookmarks, passwords and other settings.
I went through all this because, even after Steffen’s steps and then removing ACR, all the preferences created by it are left behind which could potentially skew the perceived results of the new preference (lots of extensions.checkCompatibility* preferences; couldn’t it be a bit smarter?)
If any extensions.checkCompatibility.* prefs are affecting how the Add-ons Manager determines compatibility, there will be a notification at the top of the extensions list saying so, with an “Enable” button that will remove that pref.
As someone who has (just brought up MrTech…) 139 extensions installed (18 disabled), I’m ***ESPECIALLY*** interested in how these will fair when I finally upgrade out of what is becoming my self-imposed ghetto (FF3.6.24/TB2.0.xx)…
FF — look at the stability numbers…give me a reason to upgrade — (hint 64bit parity (equality) on Win; mac has it, linux has it…; that would likely sucker me in…)…
But everything I see is about incompat extensions, and a huge compat nightmares…
Not to mention arbitrary and random UI changes forced upon users at designer’s whims…(have to make sure there’s an extension to fix that before I upgrade)…
(I think FF “had an extension ‘that'” , long before something had an ‘app’ for things…)…
But I am seriously interested in how my addons will fair.
I’m very familiar with normal things done to make them work…I continue to use extensions well past their ‘best retired date’… Which thankfully has been made easier with some of the tools (maybe MR?) that allowme to remark things compat…w/o having to go manually edit the files (ok, so I had a script that ran through and updated the versions in all of them, but it WAS manual at one point, and I had to write the script!)…
I’d love the opportunity to upgrade and have my extensions work…especially any additional extensions required to restore the browser to my current look/feel…
I’ve TRIED others…and settled for what I have…I can have ToT, or on the side, or wherever, chome/nochrome, addr bar menubar, ll all or none…(which gets freaky, but with autohide .. everything can be hidden)…
I still have problems moving windows around without a chrome bar on top…I have so many windows open at once, trying to find a STOP button where I can know I can drag and not cause some action, is too much work.
Anway…though I would let you know, .. some of us who have hung on to FF3 for dear life are because of their close to 140 extensions…and all the UI changes will have to fix after the fact.
(TB had other issues…like defaulting to D/l my 15GB IMAP store into my 2GB roaming profile — increasing it to 17GB…BRILLIANT design decision… SPECTACULAR…downloading a remote ‘file system’ (IMAP has full FS semantics), when the whole reason it was put remote was to have it in 1 central loc where there was sufficient spce for it, IS ONLY EXCEEDED in brilliance — by the [?]decision to copy it into a users ROAMING profile… yes, I know can turn it off.. tried 3 times and it still kept doing it…I expect to try again…someone threw a registry setting (about:config) at me, that might do the trick…just haven’t had the courage …)…
So looking foward to seeing how this works out… If you want list of my extensions I can send you an MR report…(marking this entry to notify me by mail of followups)…
Thanks,
Astara
Progress implies change. There will always be changes in the UI/behaviour, and the UI/behaviour can’t possibly be perfect for every single user. But that change has been made in order to try to make things better. I suspect some of your addons that “fix” Firefox for you will no longer be needed, while you may find other things you don’t like that there will be new addons for. For those cases, you’ll just need to try out the new version. There’s a huge difference between Firefox 3 and Firefox 8 (the latest release version) – in fixing up the UI, improved performance, and many more modern web platform features (not to mention security fixes).
Thank you for doing this work! Smooth update is the most important feature in a browser, because without it, we don’t get to deliver other features.
I’m worried about allowing add-ons opt out of compatible-by-default. The problem being solved is that add-on manifests have incantations that were put there before the add-on author saw the future version of Firefox and those incantations tell Firefox that the add-on will be incompatible with a future version that the add-on author has not even seen yet.
Letting add-on authors opt out of compatible-by-default puts us back in the situation where incantations put by add-on authors in the manifest ahead of seeing the future version of Firefox block updates.
What’s the reason for letting add-on authors opt out of compatible-by-default?
Also: Does the binary component check differentiate between XPCOM binary components and jsctypes binary components (and allow the latter to participate in compatible-by-default)?
The opt-out should be used very rarely and cautiously by addon authors. But it is needed, IMO – there will be addons that are just a lot more fragile than others, or may only apply to specific versions of the application.
The binary component checking is done by reading the chrome.manifest files, looking for the binary-component instruction. So if an addon ships a .dll that it loads via js-ctypes (ie, it isn’t a XPCOM component), that .dll won’t be detected as a binary component. I have a bug on file to also parse the OS/ABI/version flags for cases where a binary component is only used on some OSes or older application versions (eg, as fallback when js-ctypes isn’t available), but that’s a pretty rare edge-case.
What about Themes? The default theme changes continuously. Since Firefox 4.0 there hasn’t been one release that hasn’t introduced some new feature or change that requires Theme support. Since the UX branch work began and changes from it are landing we can expect even more required support for themes. Any plans to ignore themes or should theme authors include the install.rdf switch just to make sure?
Themes always use strict compatibility (ie, the old method, where they need to declare exactly what they’re compatible with), for exactly the reasons you mentioned.
There has been a bit of a debate over this – I asked someone who thought themes should be compatible by default to post a thread to the dev-apps-firefox mailing list:
https://groups.google.com/forum/#!topic/mozilla.dev.apps.firefox/HDFiu3mJ3Ws
General consensus there was that themes should not be compatible by default, which matched my original assessment.
good news firefox aurora makes addons compatible by default
Pingback: Oxymoronical » Blog Archive » The add-ons manager is about to get more Unfocused
Pingback: Firefox Add-On Compatibility | eschew it all
Pingback: The Add-ons Manager and I are rather good chums « Blair’s Brain
Comments are closed.