The humble opinions of Dave Townsend
Done:
Regular bug triage (epic bug triage deferred)
Tinkering with the Bugzilla APIs
Cleared out my inbox and review queues
Next:
Formalise priorities for the Jetpack team
Next week I…
Next week I'll probably be in and out randomly as relatives and friends are going to be in town
Done:
Landed UI to allow users to check they have the add-ons they want on next upgrade (bug 596343)
Landed UI to allow users to confirm that they want third-party add-ons before they are enabled (bug 476430)
E10S planni…
For some time now Firefox for mobile has had this nice feature where add-ons could embed their preferences right into the list of add-ons, no need to open a whole a new window like add-ons for desktop have to. During the development of Firefox 4 we were a little jealous of what the mobile team had done and so we drew up some ideas for how the same functionality would look on desktop. We didn’t get time to implement them then but I’m excited that someone from the community stepped up and implemented it for us. Not just that but he made the code shared between mobile and desktop, added some new option types and made it work fine for restartless add-ons which are unable to register their own chrome.
The basic idea is simple. Create a XUL file containing a list of <setting> elements. Different types of settings are possible, checkboxes, input boxes, menulists, buttons, etc. Each one shows up as a row in the details view for an add-on in the add-ons manager. The XUL file can either be just added to your XPI (call it options.xul) or referenced by the optionsURL option in your install.rdf.
Get it right and you’ll see something like this:
I want to thank Geoff Lankow (darktrojan on IRC) for his awesome work getting this done. This feature is now in the Aurora builds and it’d be great to get add-on developers playing with it. Geoff even wrote up some detailed docs to help you out.
As a bonus Geoff also implemented support for in-tab preferences. This makes Firefox load an add-ons options UI in a new tab instead of a new window. Setting the optionsType property to 3 enables this.
Keeping the software you use up to date is a crucial part of keeping yourself safe while browsing online. At Mozilla we work hard to help you get the most up to date version of Firefox and all the add-ons you have installed. For some time now security updates for Firefox have been installed without you needing to do anything. In Firefox 4 we made extension and theme updates behave similarly.
Plugins, like Flash, Quicktime and Java for example, are a little more difficult to update in this way though. They tend to require explicit permission to install new versions and so we haven’t quite gotten to the point of doing this completely automatically. Instead we developed the plugin check page which can quickly and easily tell you which of the plugins you have installed are old and need updating. It will also tell you where to go to update them.
The latest version of Firefox currently in beta makes it easier to get to the plugin check page. Simply go to the Add-ons Manager, click on the Plugins section and there is a link at the top of the page to check if your plugins are up to date.
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:
There are also some disadvantages:
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.
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.
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.
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.
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.
One of the nice features that we added to the add-ons manager in Firefox 4 was support for custom add-on types that could be treated the same way as the built-in types, even showing up in the same UI if you did a little work. I blogged a basic example of how to do this and I know since then Greasemonkey and Stylish have been using the support.
A few days ago (and now in Aurora builds) I landed some improvements that simplify the hardest part of this, making the UI appear.
Previously in order to add a new type of add-on and have it appear in the add-ons manager you would have to do two things, first tell the add-ons manager module that you supported add-ons and secondly manually create some elements in the UI to allow the user to view them. These two things have now been combined:
AddonManagerPrivate.registerProvider(myProvider, [{
id: "scripts",
name: "User Scripts",
uiPriority: 3500,
viewType: AddonManager.VIEW_TYPE_LIST
}]);
This registers the provider as before but also tells the module that your provider supports an AddonType with the ID “scripts” and some other information. The documentation explains a little more about the properties. You’ll note it passes an array to allow for providers registering multiple types.
Currently you only need to do this if you want your add-on types to show up in the UI, however we may start requiring providers to register their types to help speed up some of the API calls. If you want to register your type and not have the UI automatically show it just don’t give it a viewType.
Some of the changes we had to make may have broken some add-ons that have been doing this the hard way in the past. Here are the once I’ve identified and some ways to work around the problems:
The UI now requires that if you’re displaying your add-ons in the regular list view then it must have been registered. If you only care about supporting Firefox 6 and higher then you can just remove your code for adding your type to the category list, if you want to support both then you should either only do that on versions before Firefox 6, or you could always manually add your type to the UI but also register your type with no viewType.
We made some changes to the IDs of elements in the add-ons manager UI, we dropped the “s” on the end of the type selectors. category-extensions became category-extension as an example.
Because we now build the list of types to display in the UI (even the built-in types use the same type registration I’ve talked about here), the elements for those types aren’t in the UI until after the main initialize function for the window has completed. If you try to use overlays that refer to those elements or if you run script that tries to find these elements before the initialize function completes (it is a load event listener) then they won’t exist and you’ll probably find things broken.
A long long time ago (I can still remember…) we changed the preference you use to disable compatibility checking for extensions. We still aim for users to instead use tools like the Add-on Compatibility Reporter to handle this (especially since we are going to start crowdsourcing data from it), but for developers who don’t want to install that but still want to use extensions on their nightly builds the new rapid release model would mean setting a new preference every 6 weeks.
We’ve now changed this and any nightly, try, or self-made builds (anything not on the aurora, beta or release channels) will instead use the single preference extensions.checkCompatibility.nightly from now on, regardless of version. This will be available from tonight’s nightly onwards.
We were amusing ourselves on IRC yesterday by showing each other the first patches we ever submitted to Mozilla and I suddenly noticed that mine was exactly 6 years ago from today. It was the ridiculously trivial bug 292411, nothing more than a typo correction really. I can remember being quite excited that I had found a bug I could fix and rushing to get it submitted before anyone else. Of course in those days there were no real automated tests so it was a pretty simple process and within a day my patch was reviewed and landed for Firefox 1.5.
That wasn’t my first introduction to the community, just the next step in a long list that probably started with trying out Firebird in late 2003. I first complained about issues in early 2004 on Mozillazine (no-one answered I note!), then I really started to get involved in nightly testing in late 2004. In early 2005 I wrote my first extension in response to complaints from nightly testers over some UI that had been removed. I mostly remained focused on helping nightly testers out with my extensions and in May 2005 I released what was originally known as Build ID Copier but eventually morphed into Nightly Tester Tools. I’m now basically uninvolved in the ongoing development of that since it has been taken up by the awesome Heather Arthur.
I was clearly doing the right things since in 2006 Mozilla invited me to the Firefox 2 summit in Mountain View where I finally got to meet all the people I had been talking with on IRC. Also I recall there were drinks. This (mostly the people, but also the drinks) helped convince me that I wanted to be doing this sort of thing more so I applied and in May 2007 I started working on the Firefox team full-time.
I recall in my first few days not really knowing exactly what to do so I just did what I had been doing with my evenings and weekends already, picked out some bugs and set to work fixing them. I guess this was the right thing since I’m still here now. By the time I was at my second summit in Whistler in 2008, Rob Strong was ceding responsibility of the add-ons manager to me and eventually Benjamin Smedberg decided he’d have a lot less work on his plate if he made me the owner of the whole of toolkit. In 2009 Mozilla were kind enough to help me move to the USA which has meant I can now mentor interns and really just get more involved with the rest of the team.
It’s kind of crazy to look back and see how long I’ve been involved with Mozilla, and I know I have been around for far shorter than many people. 7 years during which I have been under 3 different employers, switching from being a student, through academia and into the workplace and never once have I lost interest in what Mozilla was doing or felt like it was time to give up and start doing other things. To be sure I have over time gained a healthier work-life balance, rarely do I code into the small hours these days but on the whole I think that is probably good for my sanity. Firefox still gives me new challenges and pushes me to come up with clever solutions, and I’m not sure I could ask for more.
Done:
Tidying up the loose ends of things still in progress
Cleaned out my review queue
Work on simulating nsIFile enough to emulate filesystem failures while installing add-ons (bug 653835)
Trying to test some weird edg…
Done:
Partied in Vegas
Evaluated an issue with softblocking and have it mostly tested and fixed (bug 648599)
Meetings meetings meetings
Next:
Land the softblocking fixes before the bra…