Changing the checkCompatibility preference

Back in the mists of time I wrote some code to make nightly testers’ lives easier by giving them a simple preference to flip if they wanted to be able to install and use incompatible extensions. It’s been more than three years since then and the use of this preference has grown beyond its original use. It is now something recommended to regular users everywhere from forums to comments in news articles as a way to use their extensions in the new major Firefox releases.

Don’t get me wrong, letting users upgrade sooner than they otherwise might is a good thing, but the preference is a dangerous beast. It is pretty simple for a user to set the preference and then forget about it leaving them able to install incompatible extensions that break their Firefox without realising it. This costs Mozilla time as well since we get quite a number of bug and crash reports to look at that turn out to be caused by extensions that are dutifully marked incompatible with the user’s Firefox.

We’ve been mulling over ways to change this for a while but now we’ve actually gone and done something about it. We still want nightly testers and early adopters to be able to use incompatible extensions if they need to but we also want to make the preference not be a one shot deal that lasts till the end of time. The plan we’ve come up with is to change the preference’s name with the Firefox version, so for Firefox 3.6 (and all security releases) the preference will be extensions.checkCompatibility.3.6. When switching to a future 3.7 testers and users will have to set a new pref extensions.checkCompatibility.3.7 to say they still accept the risks of running with incompatible stuff.

Nightly users will have to make the changes slightly more often since the preference will also track whether the version is one of the development alphas or betas, so for the 3.6 betas the preference would be extensions.checkCompatibility.3.6b, for the current trunk extensions.checkCompatibility.3.7a. These are just normal preferences of course, if you frequently switch between different Firefox versions you can just set both necessary preferences. The change should land on the trunk in the next day or so and then the 3.6 builds a day or so after that.

There is just one oddity, if you’re testing nightlies and you update to a build with the change then you likely won’t notice any of your extensions disabling themselves, that won’t happen till either you toggle the pref or you switch to a build with a different Firefox version number in it.

Update: For more in-depth information this change was made in bug 521905.

34 thoughts on “Changing the checkCompatibility preference”

      1. That’s a “Core” change made only on the Trunk I suppose, so not in builds based on Gecko 1.9.1 or earlier, such as SeaMonkey 2.0 or the upcoming Sunbird 1.0 (another Toolkit app)?

        1. It has been made to the trunk and 1.9.2 branches, so anything released off either of those will be affected.

  1. And I for one will go on recommending people use set it. Why? Well lets look at what happened when Firefox 3.5 came out.

    I have several extension that were marked as compatible with the beta release, but not the final. Unfortunately you can’t say “well my extension works in the beta 4 so it will with the final” AMO will simply not let you upload it. So I dutifully changed the max version via AMO so users could still update fine. Turns out this does not work very reliably. I had plenty of people on my forum (http://codefisher.org/forum/) asking about it.

    So you go upload a new version. Which cool, takes a month or so to get approved… That is if it not rejected for stupid reasons. For example on one extension I was told I have to provide source code with any binary components. Excuse me there is an SVN link on the extensions home page – did they even read that? – obviously not since they accepted it when pointed out.

    Sorry for the rant, but you guys just keep making it harder. I get peanuts for what I do, please don’t make managing users any harder.

    1. We’re also trying to make it easier for add-on developers to get their add-ons compatible with Firefox 3.6 sooner. AMO has been allowing developers to mark their add-ons as compatible with Firefox 3.6 final ever since beta 1 was released. They’ve also been fighting to get the review queue down and they are apparently now reviewing add-ons in an average of just a week.

    1. I agree the majority of nightly users probably do understand the position they are putting themselves in. It is the regular users we are more concerned with

  2. Incredibly painful… I understand why this was introduced but for us add-on developers it’s a true pain in the ass. Working with nightlies, we don’t necessarily follow when the version number is bumped and all of a sudden an extension we’re working on is gone. More important, super-useful extensions like Venkman and DOMI that don’t have 3.7a+ versions become unreachable.

  3. A Phoenix user, then a Firebird user, and now with Firefox 3.5 nightly, 3.6 nightly and 3.7 nightly all installed. One thing I have come to realise that with each iteration of Firefox, although it brings major improvement, it also brings endless frustration. Remember, this is only a browser. End users like a customisable browser that they can add the extensions they find to be useful, and tends to stick with these extensions. It seems to me that the Firefox / Mozilla development group, though doing a fantastic job, have forgotten about that in the end, it is the END USERS who are the most important….they use Firefox because of the ease of use, ease of adoption, and nice extensions. Constant changes, resulting in lose of functionality of some extensions (worse yet, some extensions actually “break” Firefox), will also result in the erosion of the user base. I cannot imagine Firefox will get such support as a browser without the large number of available extensions. To sum it up, the Firefox/Mozilla development group needs to stay with a standard for the extension/theme developers, and do not deviate from it with each version release! Not everyone knows how to tweak Firefox and modify the “install.rdf” to get some of the old extensions to work. Come on guys, development of a strong and good software matters, but the product is really there to serve the end users!

    1. The problem is that the current extension system is not set up to allow developers to write extensions that just work with any version of Firefox. They get all the power in the world because we give them access to all the internal functions that make Firefox itself work with no restrictions. Everytime we make a change to Firefox to make it faster, fix a problem or add a feature we must change some of these functions and potentially break any extensions that depend on them. It is because of this that we need to have extensions declare what version of Firefox they work in because as you quite rightly say, if you run an extension in a version it doesn’t support it can totally break Firefox. The problem we have is that because various websites recommend end users set this preference with little to no explanation of the consequences we end up with many users who don’t realise they have it set and don’t realise they are installing extensions that should never work in their version of Firefox leaving them with an unstable or totally broken browser.

      The best way around all of this is to build a better extension system that provides stable functions that developers can rely on working in the same way in all versions. That is part of the goal of the Jetpack labs project. Until then I don’t think that having end users set a new pref if they need to make old extensions work in a new major release of Firefox (and they will only have to do this when they install a new major release, not for every security release) which come along maybe every 6 months to a year is not so much of a chore.

  4. So extensions.checkCompatibility.3.6a for 3.6 alphas, extensions.checkCompatibility.3.6b for 3.6 betas, but what about rc versions.
    Is it just extensions.checkCompatibility.3.6 for 3.6 rc? Or extensions.checkCompatibility.3.6rc? Or extensions.checkCompatibility.3.6r?

  5. Not for nothing, but I see no reason to do this when your very own Nightly Tester Tools allows you to override individual add-on incompatibility warnings. (That’s how I deal with the occasional add-on that hasn’t been updated – it works great. [Ignoring the slim chance that the add-on isn’t actually compatible…])

    I believe it’s the height of irresponsibility to recommend disabling this compatibility check for /all/ extensions, which is why I was very surprised to see a Mozilla blog actually recommend this practice:
    http://blog.mozilla.com/addons/2009/01/13/the-quick-dirty-way-to-test-your-add-ons-in-fx-31b2/

  6. Another user here who stayed with you since Phoenix while making the transition from Windows to Linux to Mac OS X.

    With the road you are going down here, why not introduce another 10 checks everytime you start Firefox just to be REALLY safe, or just disable addons for betas alltogether whoreallyusesthoseanyway. You know what will happen? People will just insert extensions.checkCompatibility.x.xx up to Firefox 5 just to be never ever bothered again by “disabled for your safety” addons.

  7. Some of us have extensions that we have been using for years but have stopped being maintained by the original developer. These old extensions will never be updated to be compatible with new releases of FF. Having the ability to enable these out of date extensions is the main reason I started using Nightly Tester Tools. Removing this capability makes NTT useless to me.

    1. My apologies. It looked to me like this change was the reason why FF 3.6B3 now does not allow me to Override Compatibility on individual AddOns using NTT.

  8. How annoying. Now I’ll have to disable compatibility checking every version number change… YAY!
    So what if people start to learn this method too? You’ll just gonna generate a random property name with every version? Don’t you guys have better things to do than screwing up functionality that works perfectly?

  9. Really not liking this extensions.checkCompatibility change.
    I tried adding a new boolean with 3.6 and it didn’t work. Nor did NTT.
    Back on 3.6b1 until you sort this mess out.

    I’m on OS X.
    I copy/pasted the boolean from this page (and removed the full stop) to double check. There’s no chance I did it wrong. It just didn’t work.

  10. Simply the most retarded update in Firefox’s history (until the IU revamp of version 3.7 or 4 gets released). Why didn’t you just let the old generic “extension.checkcompatibility” setting and added your awful new “extension.checkcompatibility.[version here]” as an extra setting? I guess you thought maybe my pref.js is too short and needs one line per Firefox version (also counting alphas and betas)…
    Not to mention the fact that it took me a week to find out why my Classic Compact theme wouldn’t load anymore… This bug 521905 wasn’t a bug, but “fixing” it introduced one hell of a regression. Not to mention the fact that it had only 4 votes while a real and annoying bug like Bug 83376 (Crash loading Java Plugin if UserAgent string is changed), reported in 2001 and with 36 votes still isn’t fixed. Trying to push me more towards Opera or Chrome? Don’t push too hard, you could succeed sooner than expected…

    On a side note: +1 to Michael Buckley for the terrible extension approval delay and the random rejection reasons (a way to spare t-shirts at the cost of screwing a few thousands of users?)

    1. Leaving the old setting working would have clearly not had the effect that we intended with this change, people would have gone on recommending that to users and we would still be in the same position that we were.

      See also http://blog.mozilla.com/addons/2009/11/13/burning-down-the-add-on-review-queues/ for updated information on AMO reducing the review queues. Apparently I was slightly mistaken above when I said the average was a week, that is true for updates, new nominations are done in around 2 weeks.

      It’s also worth remembering that votes on a bug report are just a small measure of how many of a certain class of people want to see something fixed, something that is related to but not the same as how important a bug is to fix. It is difficult to truly measure the latter.

      1. And now they will be recommending the new way. The change was only successful in creating frustration for everyone.

  11. Hi, so what happened to the ability to see which extensions are working under force-installed mode? Does anyone else regret not being able to see that anymore? There used to be a red exclamation mark next to all the extensions which are technically incompatible (even after I overrode compatibility with NTT). This time, after I enabled NTT and did “override all compatibility”, it disappeared. 🙁

Comments are closed.