Our success in switching to the new rapid release cycle for Firefox has stirred up lots of excitement in the community and I wouldn’t be surprised if that intensifies when we ship the next update to Firefox in 8 weeks time. People keep pointing out that everytime we update Firefox we break add-ons so surely faster releases means add-ons will get broken faster. Many people don’t really understand why Firefox updates should break add-ons anyway so here is my attempt at an explanation and how maybe rapid releases aren’t such a bad thing after all.
The crux of the matter is in how deeply we allow add-ons integrate with Firefox. Most browsers separate add-ons from their code using what can be called an add-on API. All the add-on can see and use is what the browser makes available through that API and this is normally a restricted set of functionality. Firefox has no such separation. Add-on code runs in exactly the same setting as the browser code, they can call any of the internal functionality that we write to make the browser work in the first place.
There are big advantages to the Firefox way:
- Add-ons can do basically anything, allowing really complicated add-ons like Firebug and NoScript to exist.
- Authors don’t have to wait for features to be exposed through some API to be able to use it, as soon as the feature is in the application add-ons can use it.
There are also some disadvantages:
- Add-ons can do basically anything so you should be wary about installing add-ons from people you don’t trust!
- Because we aren’t forced to provide an API specifically for add-ons sometimes what is there can be cumbersome for add-ons to use.
- Add-ons rely on internal functions, if we make a change to one then it breaks the add-on.
It is that last point which explains why Firefox updates break add-ons. Any time we add, remove or change some code we run a risk that some add-on depends on it and so will break. Some bits of code are more important than others but we have such a vast library of add-ons now that it’s probably getting to the point where almost everything is in use. When people say that Firefox updates shouldn’t break add-ons what they don’t realise is that they’re asking us to stop making changes to Firefox: no new features, no bug fixes.
How does the Add-ons SDK fit in?
With the most recent update to Firefox we also made the first official release of the new add-ons SDK available. These are tools designed to make developing add-ons for Firefox easier and faster and they largely serve as an add-ons API sitting between the add-on and Firefox with one difference, the API is actually a part of the add-on so you can actually write your own additional APIs to supplement those in the core SDK.
Add-ons written with the SDK (and only using the core APIs) gain a lot of the benefits of add-ons for other browsers. The APIs in the SDK can be far more stable than those in the browser itself, as the browser code changes the internal SDK code can adapt to match allowing add-ons to work just by rebuilding with the newer SDK. This makes the problem of Firefox updates much smaller for those that can move their add-ons to the SDK.
I don’t foresee a future where the only add-ons are SDK based though. We’d lose too many really important add-ons that way so the SDK doesn’t completely solve the problem.
How does rapid release affect the problem?
As I’ve said, when Firefox updates it breaks add-ons. Ask any add-on author how much fun it was fixing their add-ons to work from Firefox 2 to Firefox 3 or 3.6 to 4 and you’ll probably get some pained expressions. Now think about how in the past we would do a Firefox update about once a year, now we are talking about it being more than eight times a year. Having given up maintaining my own add-ons I can hardly blame authors who are concerned that they won’t be able to keep up with the pace.
It actually isn’t all bad though. It’s not like we are making more changes than we were before, we’re just releasing them sooner in bite-sized chunks. Instead of one update a year that probably changes every piece of functionality an add-on might use we do 8 smaller updates, each one touching smaller parts of the code. This means it is more likely that an add-on can survive an update than before.
The stability of updates is a key change too. It used to be that add-on authors might choose to wait for the RC stage of an update before updating their add-ons. We’d make so many changes even during the beta cycle that sometimes it wasn’t worth trying to keep up. In our new cycle though there is a full 6 weeks in the beta cycle before release during which time almost nothing changes, no new features, extremely limited bugfixes, just things to solve any stability issues that have been found. Before that there is 6 weeks in the aurora cycle which again should be largely change free. Some new features might get removed at this point and there is the possibility of larger bugfixes, but based on the two aurora cycles we’ve had so far there are far fewer changes going in than there were in the final beta stages of Firefox 4.
I actually think that rapid releases can make it easier for add-on authors to keep up. Sure you have to check your add-on more often but most of the time it will probably just work, if not the scope of change is likely to be smaller and you have 12 weeks of pretty stable code to build against.
Why not just mark add-ons as working when they are?
A pretty common question asked is why we don’t just mark add-ons as working in the new update of Firefox when we know they are. The good news is that we actually are starting to do this. As we make changes to Firefox we plan to keep track of which changes have the potential to affect add-on compatibility and automatically scan add-ons on AMO to find ones that might break.
In the run up to the most recent update of Firefox we found nearly 4,000 add-ons that were unlikely to be affected by the update and just marked them as compatible with no need for the add-on author to do anything. For the others we emailed the author to explain what problems we had found. You can read more about the compatibility checking process we’ll be using.
As well as automated tools the add-on compatibility reporter provides add-on authors valuable feedback on how their add-ons are performing in Firefox. Users can install this tool and then use normally incompatible add-ons and file reports on whether they are working or not.
Faster releases are good for add-ons
Rapid release is all about getting new features into users’ hands faster. It has a side effect though, it gets new features and APIs into add-on authors’ hands faster too. Back when I was still writing add-ons I would frequently do so in response to some fantastic new thing that had been added to the Firefox nightlies. It could then be up to a year before I’d be able to release an add-on that normal users could actually make use of, by which point I’d often have lost interest in it.
I think that on the whole faster releases will be a good thing for add-ons. Add-on developers can get exciting new features into users’ hands faster and should only need to make smaller updates with each new Firefox. The new automated tools we are building to help authors understand when and why their add-ons are no longer compatible are going to be a massive improvement, especially as we get better at identifying the changes we make in Firefox that will affect add-ons.
Time will tell of course, but I do believe that the overall work an author has to do to keep an add-on up to date with Firefox is going to drop with the new rapid release cycle even though they may have to do something more often.
17 thoughts on “Why do Firefox updates break add-ons?”
> Faster releases are good for add-ons
I understand what you are trying to say, but I totally disagree.
I’m not going to update my add-ons to support new features because most of them break on older Firefoxes.
In the end, as long as I have to support old Firefoxes (which I will for a long time), my add-ons will always be common denominator.
The idea is, though, that old releases fade away fast. When that becomes a reality, you don’t need to support old Firefox releases.
Like how IE6 faded away with the releases of IE7, IE8 and IE9?
Not all developers retain a long term interest in their add-on, even if the ongoing cost is kept low; they just switch browsers, develop other interests, etc.
As a Firefox user, I do make use of add-ons which are abandoned by their developers. With the old regime I knew that I could continue using a setup that worked for me and my work at least for the year or two life of that browser release — even if the developer didn’t do anything at all! Now, I can’t trust that any particular extension will be around, it makes it more risky to start depending on it in the first place.
Add-ons are FF’s main competitive advantage at the moment — performance may be catching Chrome, but it’s hardly ahead and their UIs seem to be converging. If I’m scared to depend on add-ons other than the really big popular ones, why use FF at all?
This is true, rapid releases may cause unsupported extensions to die off quicker than they otherwise would have. Hopefully as more and more add-ons switch to the Add-ons SDK though this problem will become a lot smaller.
What about the Firefox LTS plans? I read something about it and was wondering who inside Mozilla is playing with this idea?
Imagine if Windows, Linux, and OSX dropped a new version of the operating system every two months. Imagine Mozilla did not have the resources to test Firefox against these new versions. Some releases would work. Some would crash. What do you think Firefox users would do? Abandon Firefox in waves corresponding to the releases that did not work so well.
This is the corner that Mozilla is painting it’s addon developers into.
As I said, I believe that it is going to take less work to keep up with rapid releases than it did with the old process. You may disagree, I guess we’ll learn more as we get more into the swing of the new release process.
Linux basically does release a new version every two months, if not more frequently. Linux isn’t a singular thing, there are a billion distros with various combinations of kernels, libraries, and desktop environments. And yet somehow the world has not ended.
If Linux obsoleted every piece of software you ran against it everytime there was an update to the OS, the world of Linux would have ended long before it began. Not the finest analogy…
But Firefox has the ability to test against the Linux releases and, perhaps more important, Linux developers use Firefox and thus pre-test Linux regressions. Neither kind of test occurs with most addons. Firebug tests against firefox pre-releases. It’s huge drain on our project because the burden of isolating the Firefox bug falls on us. Few add-ons can use this approach.
A problem I have is that quite often, Firefox and Thunderbird addon authors simply “forget” that SeaMonkey exists: Time and again, I’ve made an addon work in SeaMonkey merely by adding a SeaMonkey section in its install.rdf. If I then use the Compatibility Reporter to “report that the addon still works”, will the author get the message that he ought to add SeaMonkey as a supported application?
oops: …by adding a SeaMonkey (less-than) targetApplication (greater-than) section…
Indeed, the automatic evaluation for incrementation of the add-ons’ maxVersions has worked very well here (the first time since Firefox 2.0 that all my important add-ons have been compatible on release day).
(For an add-on developer, this also decreases the incentive to try a switch to the SDK if it provides all you need.)
>Why do Firefox updates break add-ons?
Has it broken your own add-on Nightly Tester Tools. (which was recently modified regarding compatibility, with a recommendation to employ the add-on Compatibility report ).
Nightly tester tools is was listed as not compatible on the Nightly. Using Compatibility Reporter it will the run. I have not tested it properly but for instance its function to report the Build works – “Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110706 Firefox/8.0a1 ID:20110706030833” .
you’re not even wrong.
Comments are closed.