addons on Oxymoronical

A new owner for the add-ons manager

Mon, 15 Aug 2016 16:29:33 +0000

I’ve been acting as the owner for the add-ons manager for the past little while and while I have always cared a lot about the add-ons space it is time to formerly pass over the torch. So I was pleased that Rob Helmer was willing to take it over from me.

Rob has been doing some exceptional work on making system add-ons (used as part of the go faster project) more robust and easier for Mozilla to use. He’s also been thinking lot about improvements we can make to the add-ons manager code to make it more friendly to approach.

Delivering Firefox features faster

Mon, 05 Oct 2015 11:20:28 +0000

Over time Mozilla has been trying to reduce the amount of time between developing a feature and getting it into a user’s hands. Some time ago we would do around one feature release of Firefox every year, more recently we’ve moved to doing one feature release every six weeks. But it still takes at least 12 weeks for a feature to get to users. In some cases we can speed that up by landing new things directly on the beta/aurora branches but the more we do this the harder it is for release managers to track the risk of shipping a given release.

Making communicating with chrome from in-content pages easy

Mon, 23 Mar 2015 08:34:24 +0000

As Firefox increasingly switches to support running in multiple processes we’ve been finding common problems. Where we can we are designing nice APIs to make solving them easy. One problem is that we often want to run in-content pages like about:newtab and about:home in the child process without privileges making it safer and less likely to bring down Firefox in the event of a crash. These pages still need to get information from and pass information to the main process though, so we have had to come up with ways to handle that. Often we use custom code in a frame script acting as a middle-man, using things like DOM events to listen for requests from the in-content page and then messaging to the main process.

Firefox now ships with the add-on SDK

Wed, 15 May 2013 15:31:59 +0000

It’s been a long ride but we can finally say it. This week Firefox 21 shipped and it includes the add-on SDK modules.

What does this mean? Well for users it means two important things:

Smaller add-ons. Since they no longer need to ship the APIs themselves add-ons only have to include the unique code that makes them special. That’s something like a 65% file-size saving for the most popular SDK based add-ons, probably more for simpler add-ons.
Add-ons will stay compatible with Firefox for longer. We can evolve the modules in Firefox that add-ons use so that most of the time when changes happen to Firefox the modules seamlessly shift to keep working. There are still some cases where that might be impossible (when a core feature is dropped from Firefox for example) but hopefully those should be rare.

To take advantage of these benefits add-ons have to be repacked with a recent version of the SDK. We’re working on a plan to do that automatically for existing add-ons where possible but developers who want to get the benefits right now can just repack their add-ons themselves using SDK 1.14 and using cfx xpi --strip-sdk, or using the next release of the SDK, 1.15 which will do that by default.

The Add-on SDK is now in Firefox

Fri, 01 Feb 2013 22:06:43 +0000

We’re now a big step closer to shipping the SDK APIs with Firefox and other apps, we’ve uplifted the SDK code from our git repository to mozilla-inbound and assuming it sticks we will be on the trains for releasing. We’ll be doing weekly uplifts to keep the code in mozilla-central current.

What’s changed?

Not a lot yet. Existing add-ons and add-ons built with the current version of the SDK still use their own versions of the APIs from their XPIs. Add-ons built with the next version of the SDK may start to try to use the APIs in Firefox in preference to those shipped with the XPI and then a future version will only use those in Firefox. We’re also talking about the possibility of making Firefox override the APIs in any SDK based add-on and use the shipped ones automatically so the add-on author wouldn’t need to do anything.

What is Jetpack here for?

Fri, 26 Oct 2012 18:27:17 +0000

Who are the Jetpack team? What are they here for? A lot of people in Mozilla don’t know that Jetpack still exists (or never knew it existed). Others still think of it as the original prototype which we dropped in early 2010. Our goals have changed a lot since then. Even people who think they know what we’re about might be surprised at what our current work involves.

Let’s start with this basic statement:

WebApp Tabs, version control and GitHub

Mon, 07 Nov 2011 00:59:28 +0000

The extension I’ve been working on in my spare time for the past couple of weeks is now available as a first (hopefully not too buggy) release. It lets you open WebApps in Thunderbird, properly handling loading new links into Firefox and making all features like spellchecking work in Thunderbird (most other extensions I found didn’t do this). You can read more about the actual extension at its homepage.

Overlays without overlays in restartless add-ons

Mon, 31 Oct 2011 01:43:46 +0000

Perhaps the most common way of making changes to Firefox with an extension has always been using the overlay. For a window’s UI you can make changes to the underlying XUL document, add script elements to be executed in the context of the normal window’s code and add new stylesheets to the window to change how the UI looks.

Restartless add-ons change this around completely, the normal overlay and style-overlay mechanisms just aren’t available to restartless add-ons and this is likely to remain true for a while, these methods don’t clean up after themselves when the add-on is uninstalled.

Adding add-on preferences to the Add-ons Manager

Thu, 07 Jul 2011 19:06:32 +0000

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.

Unloading JS modules

Thu, 07 Jul 2011 18:26:44 +0000

One of the problems with writing a restartless add-on is that you have to be careful about undoing anything your add-on does when it is told to shutdown. This means that right now some features of the platform can’t be used as we have no way to undo them. Recently I made this list a little shorter by making it possible to unload JS modules loaded with Components.utils.import().

Just call Components.utils.unload(uri) and the module loaded from that URI will be unloaded. Take care when you do this because something might still have references into it which will stop working. Firefox also caches the module’s code for fast loading the next time around. The add-ons manager clears this cache when your add-on is updated or uninstalled so you mostly don’t have to worry about it but if you do something strange like unload a module, manually alter the file and then import it again you won’t get the latest code.

Making it easier to check that your plugins are up to date

Thu, 07 Jul 2011 17:48:31 +0000

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.

Why do Firefox updates break add-ons?

Sat, 25 Jun 2011 00:25:22 +0000

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.

Creating custom add-on types just got easier

Wed, 25 May 2011 19:01:53 +0000

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.

How to disable extension compatibility checking on Nightly builds of Firefox

Tue, 24 May 2011 22:26:58 +0000

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.

What's next for the Add-ons Manager?

Tue, 08 Mar 2011 22:52:14 +0000

Firefox 4 is just around the corner and it’s great to look back over just how far the Add-ons Manager has come since Firefox 3.6. In fact if you want to see the full history look at my earlier post that shows its evolution since Phoenix 0.2. We set out with some pretty lofty goals for Firefox 4 and I’m pretty excited at just how many of them we achieved. I hope everyone appreciates the hard work that Blair, Boriss, Justin, Henrik, Ben, myself and all the others put in to get us to where we are today.

Playing with windows in restartless (bootstrapped) extensions

Wed, 19 Jan 2011 20:14:27 +0000

Lots of people seem to be playing with the new support for restartless extensions (also known as bootstrapped extensions) coming in Firefox 4. Nothing could make me happier really. I’m not sure I can remember ever helping implement something which is will hopefully turn out to be a game changer for extension development in the future. The technical details of restartless extensions are talked about in a few places but one thing that is missing is what I think is probably going to be the most common code pattern in these extensions.

Firefox 4 and the Add-ons Manager at Add-on-Con

Fri, 10 Dec 2010 04:52:05 +0000

As I mentioned before I was part of a presentation at Add-on-Con this year. Myself, Boriss and Justin talked about the new UI changes in Firefox 4 and about the main changes to the add-ons manager. If you’re particularly interested the slides are available here though I guess slides are often just tiny snippets of info from the actual session so if anything catches your eye you’ll need to get in touch and ask us about it.

Add-on-Con is here!

Fri, 03 Dec 2010 22:32:06 +0000

Next week is Add-on-Con 2010 and if you do any work in the add-ons space then you’re probably going to want to take a look at what is going on and hopefully sign up to attend. There are two days this year, one for some training and then the traditional day for keynotes and business/development tracks. I’ll be there for all of the main day and while I don’t think I am going to make the training day I should be there in the evening for the Mozilla party, be sure to sign up.

Minor change coming to the interface amIWebInstallListener in Firefox 4.0 beta 8

Thu, 25 Nov 2010 00:27:48 +0000

We’re past API freeze so any API changes should be getting announced and communicated. In this case the change is tiny and unlikely to affect anyone. Have you heard of the interface amIWebInstallListener? If not then you can probably ignore this.

If you’re interested it is effectively what the add-ons manager backend code uses to communicate messages about webpage initiated add-on installations. An add-on or application might provide its own implementation if it wanted to provide its own UI for installs. Or an add-on might call it to get the normal UI to show up for some other cases but this is pretty rare.

Don't miss an exciting opportunity to shape the future of Firefox 4!

Wed, 01 Sep 2010 23:31:11 +0000

You might have heard of this web-browser. It’s called Firefox. You may have also heard that a new version is due out soon. As my part in its development I have helped completely reshape the way the add-ons manager looks. The good news is that the large bits of the changes are pretty much done, pretty much all that is left is a bunch of UI tweaks and some small behaviour changes.

How to extend the new Add-ons Manager (or how I built a simple greasemonkey clone in an evening)

Fri, 09 Jul 2010 22:30:56 +0000

One of the goals of the new add-ons manager API was to create something that was itself extensible. A couple of times in the past we’ve had to add new types of add-ons to the UI like Plugins and Personas. In both cases squeezing them into the UI was something of a kludge involving a bunch of custom code for each case. We already have a number of new types of add-ons that we want to add, things like search plugins which are currently managed by their own custom UI.

Introducing the new Add-ons Manager

Wed, 07 Jul 2010 00:51:59 +0000

Add-ons have really been an integral part of Firefox ever since before its first release. In fact Firefox has had an add-ons manager of some form since version 0.2 (which was at that time called Phoenix). Firefox 4 will include a completely redesigned add-ons manager and while many nightly testers will have already seen our work, now the beta release is out I wanted to talk about some of the new features it includes. If you’re interested I’m also writing a companion piece that talks about the history of the add-ons manager from its first appearance through to what the future may bring.

History of the Add-ons Manager

Wed, 07 Jul 2010 00:51:36 +0000

With all of the work that has gone into the new add-ons manager for Firefox 4 I thought it would be interesting to take a quick look back at the history of this part of Firefox and a quick look at what the future may hold.

Phoenix 0.2

Even in the earliest versions of Firefox, extensions were supported using the old XPInstall style packages. These had some pretty fundamental problems though in that there was no built in support for uninstalling extensions nor any way to disable them. There wasn’t even an extension manager window to see what you had installed at first. The very first time that a list of extensions and themes appeared in Firefox was way back in version 0.2, back when the product was called Phoenix. It was a very basic user interface and appeared inside the preferences window.

Multiple breaking changes are coming for components in extensions

Mon, 14 Jun 2010 23:45:50 +0000

Are you an extension or application developer? Have you written any XPCOM components, JS, binary or otherwise? If not you can probably ignore the rest of this post, unless you are interested anyway.

If you do then you might be interested to hear that your components are probably going to break in an upcoming Firefox nightly, maybe as early as next week. I’m going to blog specific examples on the changes you need to make once we have better documentation up and builds to test against, for now it is just important for you to know that the changes are coming.

Documenting the new Add-ons Manager

Fri, 04 Jun 2010 16:35:24 +0000

I’ve spent some time this week transferring all the API documentation for the new add-ons manager from the Mozilla wiki to the Mozilla Developer Network. This should now be the place to go for the definitive info.

Right now it is pretty dry, for the most part just pure API info with no examples. Before I started working more on that side of things I wanted to ask what kind of examples people might like to see documented?

Support for dropping XPI files into the extension install locations might be going away

Thu, 27 May 2010 23:22:05 +0000

For some time now Firefox has supported a way of installing extensions that involves simply copying the extension’s XPI file into one of the extension install locations. The next time Firefox runs it would pop up the install dialog for the extension and allow the user to choose whether to install it or not.

I don’t know how many people use this feature and while the code to do it (at least for the profile folder) isn’t terribly complex, it is additional code that may not be necessary. Right now the new add-ons manager doesn’t support it and I’ve heard only a couple of people comment on its absence but nightly testers are by no means representational so I’m asking a little more widely whether people have a real need for keeping this working in Firefox 4?

Add-ons manager re-landed

Mon, 10 May 2010 23:36:46 +0000

A little sort of coincidental performance regression forced us to back out the new add-ons manager last week. It has now been re-landed with added bug fixes and should be in tomorrow’s nightly.

The new add-ons manager is here

Thu, 29 Apr 2010 19:34:24 +0000

Finally, after far too much time, the new add-ons manager is about to land in trunk nightlies. I am putting together the final patches to land now. The bit most people will see is the new UI so I guess I’ll steal Boriss’ image for you to look at here with the same caveats. What you see on trunk over the next few days is just the initial steps to switching to a redesigned UI and (more importantly from my point of view) a totally new extension manager backend that will make it easier for us to improve and build upon in the future. The changes are so large that it is important to get more people testing it now while it still looks fairly unpolished so we can pick up problems that we’ve missed.

How do restartless add-ons work?

Mon, 12 Apr 2010 21:41:48 +0000

I blogged a short time ago about how we’re adding support for a new form of add-on to Firefox that can install and uninstall without needing to restart the application. Since then I’ve been finalizing a specification for how the platform will load these add-ons, trying to keep it simple but still give developers everything they commonly need. The planned specification is now available and if developers have comments then I’d like to hear them. Currently there isn’t a version of Firefox that implements it but that should change in the next day or so when I make the changes to the add-ons manager project branch and very soon when it all lands on trunk.

How we're breaking some extensions in the near future

Fri, 19 Mar 2010 22:09:31 +0000

You may have read some reports about how we’re re-implementing the bulk of the extension manager in Firefox. It’s been a long running project (something like a year since I first really started planning how to do it). Things are finally started to come together and all being well we are likely to look at landing the first pieces of this on the trunk nightlies in as little as a weeks time. I’ll be up front, this isn’t going to be a perfect landing. There may be some thing that are missing and other bits where the user experience isn’t as perfect as it will be finally. Of course there may also be bugs we have to rush to fix. Despite all this we feel that we’re about at the point where exposing it to the hands of thousands of nightly testers is the best way forward. Your eyes spot things that we miss, even things that may seem obvious to you and you’re vital to us getting these sorts of features polished and really just how they should be before they get released to the world at large in a Firefox release.

Look Ma, no restarts!

Sun, 14 Mar 2010 22:05:11 +0000

Look Ma, no restart!

This is a screenshot of some of my latest (and most exciting) work on my project to rewrite the extension manager. I’ve just implemented support for a special kind of extension that can install (and uninstall, and enable, disable, upgrade and anything else you can think of) without the user needing to restart Firefox. This is of course to allow add-ons developed on the Jetpack platform to install without restarts but the feature is going to be available to any extension author, there are just some restrictions to how these extensions work.

Broken executables in extensions in Firefox 3.6

Fri, 22 Jan 2010 18:09:41 +0000

If you are an extension developer and include executable files in your XPI package (binary or shell scripts) then you may be seeing problems in Firefox 3.6.

Back between Firefox 3.6 beta and Firefox 3.6 RC we took a small fix to the extension manager that changed how we extract the files from the XPI package. The fix involved adjusting how we accessed files to avoid hitting problems with certain anti-virus tools that would occasionally lock files in the middle of extraction making us fail to install the add-on. A side effect to this fix leaves us setting file permissions on the extracted files in a slightly different way to previously. This side effect means that the executable permission is getting stripped from all extracted files. If you try to execute these files with nsIProcess it will likely fail.

Throwing xpcom docs out into the wild

Tue, 19 Jan 2010 19:50:41 +0000

It’s been quite some time since I last worked on my prototype XPCOM component/interface viewer and I have to face facts, it’s likely to be quite some time till I do again. I haven’t even had time to update it with the data from the latest 1.9.2 and trunk interfaces. Since I’m not likely to go anywhere else with this I’d love for someone else who thinks it is worthwhile to pick it up and run with it. I’ve just done a final commit adding a README on how to use the code (though I’m sure it is lacking in key ways so be prepared to have to experiment a bit) and the full source is available in my hg repository. The code is MPL tri-licensed so you should just be able to fork and go do your own thing. I should be able to answer any questions and would love to see it get finished and really usable somewhere.

Do we need extension dependencies?

Thu, 07 Jan 2010 18:50:42 +0000

Ever since Firefox 2 we have vaguely supported a form of extension dependency. That is marking an extension as requiring particular versions of another extension.

The support is currently very limited and when a user tries to use an add-on that depends on something they don’t have they are pretty much left in the cold. While we tell them it requires something we don’t tell that what it requires or give them any easy way to download and install it.

Changing the checkCompatibility preference

Fri, 06 Nov 2009 21:31:18 +0000

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.

Third-party extension installation status

Sat, 12 Sep 2009 16:04:05 +0000

I have been remiss in not posting a status update about this in two weeks, but that is mostly because we have unfortunately had to slow down work on this feature. The problem is that a string freeze became necessary for all toolkit code (the code shared with the Firefox mobile browser and where this feature would have lived). Unfortunately this all came up over a small period when I was travelling long distances and having to take time out to satisfy immigration authorities that I wasn’t a terrorist intent on bringing down the U.S. government.

Third-party add-on notification progress, the lite edition

Fri, 28 Aug 2009 23:36:12 +0000

This week has been the Firefox work week where almost all of the team, including me, made our way to Mountain View. This pretty much means that you spend the entire week in meetings since when you’re remote it can be hard to keep in sync on everything. Of course this means that the amount of coding is pretty low for the week so there isn’t a great deal of progress to report here.

Progress on notifying users about third-party add-ons

Fri, 21 Aug 2009 18:28:41 +0000

This is a weekly status update on the feature to notify users about add-ons that third-party installers have added to Firefox. You can read more about it in last weeks blog post or on the project wiki.

Status

There has been little progress this week mostly due to waiting to see whether the doorhanger notifications UI was going to arrive in time for Firefox 3.6. It looks like it isn’t so instead we are discussing using an in-content page to describe the add-ons that have been installed and allowing users to disable them.

Supporting icons for disabled extensions

Thu, 20 Aug 2009 11:17:57 +0000

I’ve just landed code that allows extensions to include their icon in the add-ons manager view even when disabled. Currently extensions provide their icon by giving a chrome iconURL for us to load. This can only work when the extension is enabled since we don’t register the chrome otherwise. Themes on the other hand provide their icon as a simple file called “icon.png” alongside the install.rdf. Well extensions can do this too now and it will be used in preference to the iconURL but more importantly works at all times (well not before installation yet, but that is at least feasible this way).

Notifying users about third-party add-ons

Fri, 14 Aug 2009 21:48:52 +0000

You may have noticed many of the Firefox team starting to blog progress reports on Fridays. This is a part of our new plan to clearly define the main projects we are all working on and communicate a much as possible about them rather than just having users surprised to see them turn up in nightlies. So here is my report for this week:

I’ve been working on improving the level of information and control we give users over add-ons installed by other applications on the system (think Skype, Java, AV tools etc.). The work for this is being tracked in bug 476430 and on the project wiki.

Moar xpcom docs!

Sun, 05 Jul 2009 17:57:03 +0000

While many of you were out blowing things up over the weekend I spent a few days varying between getting quite a bit done and banging my head against my desk in frustration.

First I updated the XPCOM interface lists that I have been working on with the final release version of Gecko 1.9.0. A few people had asked me for it but I had hit upon the problem that I had lost some of the arcane scripts that I was using to gather the data and so I had to rebuild them first. I have dropped information about the beta versions of 1.9.1 now, just because it was less work that way, if people desperately want them back then I can probably do it.

Farewell contents.rdf

Thu, 11 Jun 2009 13:09:17 +0000

This is mainly of interest to add-on and application developers and I should stress from the outset that this is talking about changes in Gecko 1.9.2 which will first be released in whatever version of Firefox comes in 6-12 months time. Firefox 3.5 is unaffected by this change.

What was it?

Contents.rdf was the old way of performing chrome registration for add-ons. It was replaced by chrome.manifest back in the mists of time in Gecko 1.8 and Firefox 1.5 (back in 2005 as it happens). We’ve continued to support reading contents.rdf for those developers who hadn’t had the chance to make the switch but after 4 years it seems time to remove that support and clean up the code that dealt with it.

Improving the add-on install experience

Wed, 03 Jun 2009 09:44:13 +0000

Add-on developers face a bit of a challenge when it comes to helping users get the most out of their add-ons. Even once you are past the first hurdle and have got a user to install the add-on, you then need to help them get up and running quickly after Firefox has restarted. Presented with just the blank Firefox window it can be difficult for a user to know where to go next. Many add-on developers have taken to including a first-run experience to give the user some help. Display a webpage with some instructions or open a wizard to start setting up. As this practice started it was generally acceptable. Few add-ons actually did anything so it was helpful. These days though many add-ons are doing it, no doubt with more to come. It is starting to be an annoyance in some cases. Others have already been discussing ways that we can improve this.

Letting add-ons perform work during install and uninstall

Mon, 30 Mar 2009 10:31:59 +0000

One of the biggest requested items I see in the add-ons newsgroups and IRC channel is from developers asking how to perform some work when their add-on is installed or uninstalled. Previously it has been vaguely possible to do this, but there is a lot of hassle involved and it wouldn’t always work right.

As part of my roadmap for improving the extension manager we are talking about adding real support for these sorts of activities. The draft specification covers the proposal in more details but in draft it allows the following:

What's up with the extension manager?

Mon, 30 Mar 2009 10:31:46 +0000

Some time ago (wow was it really 5 months!) I blogged about some plans I have had for the future of the extension manager. I think it’s time for a short review of what it going on.

I said at the time that any of the timescales mentioned we’re very rough and certain to be underestimates, but I didn’t quite appreciate how true that was at the time. Despite tripling most of the times we’re still almost nowhere along implemented most of the ideas.

XULRunner 1.9.2a1pre builds also available

Sat, 28 Mar 2009 01:23:34 +0000

Just as I’ve made some 1.9.1b3 builds I’ve spun some builds based on the latest trunk. Feel free to use these to see how things are shaping up with the bleeding edge Mozilla code. Obviously it is pre-alpha so not for productions.

Windows runtime sdk
Linux runtime sdk
Mac OSX universal runtime i386 sdk ppc sdk

XULRunner 1.9.1b3 builds, get them while they're hot

Fri, 27 Mar 2009 18:20:49 +0000

In the process of switching from CVS to Mercurial (and behind the scenes Tinderbox to Buildbot), quite a lot of Mozilla’s build and release systems have had to be updated. Sadly one of the casualties that has yet to be resuscitated are nightly builds of XULRunner on the 1.9.1 branch and trunk. Catlee is now doing some excellent work to get these up and running, but until that gets going here are some semi-official builds using the code matching Firefox 3.1b3. I say semi-official, they were built on regular build slaves using the standard configuration, but just done by hand. I also haven’t tested all of them yet so let me know if you hit any issues, they might be good indicators of issues we’ll see with the nightlies.

Testing the background update checks

Thu, 19 Mar 2009 13:02:36 +0000

Firefox does a fair number of things in the background to help keep things up to date. This includes checking for updates to Firefox itself, checking for updates to add-ons you have installed and checking for updates to a blocklist that disables known unstable add-ons. Normally it does these things quite happily, but for developers and QA, trying to verify that these background tasks are doing what they are supposed to can be annoying. After all who wants to leave Firefox running for a day just to see if it finds a new update?

Brussels bound

Wed, 04 Feb 2009 11:12:57 +0000

This weekend is FOSDEM 2009 and I’m actually managing to attend this year. It’s kind of weird, I keep doing all this travelling to the states yet I end up having to miss all the awesome stuff that goes on in Europe for various reasons (often because I am all travelled out from the states). But I’m going to be at FOSDEM even if it kills me, which considering the snow on the roads and serious travelling I have over the next few months is a possibility. Thankfully the jetlag from Europe is a lot easier to recover from.

Updated Interface lists

Thu, 29 Jan 2009 17:27:08 +0000

I’ve generated a new database for my interface listing webapp so you can now see the current state of the 1.9.1b3pre and 1.9.2a1pre platforms. So for all you extension developers getting ready for the Firefox 3.1b3 release maybe you want to see what has changed since 3.1b2? Or since 3.0?

There are still more things I want to do with this web-app, but right now my time is being spent elsewhere so for now I’ll just keep it up to date with the beta releases. Once 3.1 final is released I’ll likely remove all the beta versions since they probably won’t be necessary then.

What is the most useful way to present interface lists?

Mon, 01 Dec 2008 22:30:51 +0000

I’ve just rolled out a small update to the interface cross reference, nothing major, just fixing a few bugs and I’ve put up what looks like the final set of interfaces for 1.9.1b2.

I’ve now figured out the best way to gather the interface lists and so the cross reference now includes all interfaces used in all 3 major platforms of Firefox. It is relatively simple for me to add the interfaces for other applications now but this got me thinking about what kind of uses people are making of this and how the multi-OS, multi-app interfaces should be presented. A few ideas came to mind:

Improving the API references

Sun, 16 Nov 2008 13:21:01 +0000

I forgot to add to my last post some information about what I currently had in mind to improve about the API reference I’ve been working on. Any further suggestions people have are very welcome, but here is the current few ideas I have.

Currently it only indexes Firefox and Gecko interfaces, in fact it only indexes those used by an OSX build of Firefox. It would be nice to be able to index interfaces for all the main applications and for all the platforms. There are a couple of issues with this. Firstly I’d want the UI to work so people viewing it could select what set of interfaces they wanted to see. Secondly actually building the lists of interfaces for each application and OS is going to be pretty tricky I think. So far I’ve resorted to building Firefox then looking in dist/idl. This works but it is time consuming. Possibly I might be able to come up with some clever nonsense to make the build system only compile idls but we’ll see.

API reference updates

Sat, 15 Nov 2008 20:29:20 +0000

Since my first announcement about my little api reference tool I’ve slowly been working on updates to make it more useful and easier to navigate around. I’ve now gone and pushed the latest version live. A few of the new features:

The main and platform lists of interfaces are split by the module where the interface lives.
Interface lists have a quick filter box, type in it to filter the list quickly.
Any interfaces used as return types or parameters are now links to get you straight to the information about them.
Full IDL support so it now lists all the special attributes and for the uninitiated they have tooltips that explain what they mean.
You can now list all usage of an interface by other interfaces.
Constants are ordered the same as in the source IDL since they tend to make more sense that way.
Includes direct links to the source IDL file.

I’ve also updated the database with the latest APIs in 1.9.1b2pre and as soon as 1.9.1b2 is frozen I’ll update it again just to be sure it has the latest versions.

Planning for the future

Tue, 28 Oct 2008 16:24:26 +0000

For some time now I’ve been throwing around ideas for new features that we may want for the add-ons manager. After lots of thought and trying to take on board comments from anyone that would pipe up I decided it was high time to put together an actual plan for what features I have decided should be pursued and what order to start tackling them.

The roadmap itself should be pretty self explanatory, just remember that nothing is ever set in stone. I’ll try to keep it updated as things change, features seem less important or new items are added. But for now this is how I see the add-ons manager evolving over the course of about the next year or so, which may be the next two versions after Firefox 3.1.

Finding API Changes

Fri, 24 Oct 2008 20:07:51 +0000

I started a small discussion on the newsgroups the other day wondering about the numbers of API changes that had landed on trunk since 1.9.0. It was a short discussion, maybe partly because all I had to go on were the vague metrics that mercurial could give me. It also evolved a little into a discussion of how add-on developers we’re meant to find out about API changes. It’s true that as developers we are getting better at trying to announce our changes as much as possible, but inevitably we miss some, and if you don’t track the announcements what then?

Should AMO allow adverts for pay-for add-ons?

Thu, 26 Jun 2008 11:09:03 +0000

Assuming you agree that paying for some add-ons is ok then you have to ask what we do about people using AMO as a marketing platform. This is a tough question since we risk devaluing AMO as a website if it just gets filled up with adverts. I don’t believe that there is an official policy on this. It is such a rare issue right now that maybe one isn’t necessary, but here are are my thoughts on what such a policy might say.

Should developers charge for add-ons?

Thu, 26 Jun 2008 11:06:34 +0000

I’m very surprised that many people are questioning whether developers should even be allowed to charge for add-ons. Traditionally it is true that add-ons have been freely available, but I’ve known of pay for add-ons for at least 2 years now (that add-on is still available so must be doing ok) and I imagine there have been some around for longer. Some companys’ entire business rests on their Firefox add-ons. That sort of situation wouldn’t exist if no-one ever paid for add-ons in some way.

Money money money

Thu, 26 Jun 2008 11:04:59 +0000

The question about developers charging money for the use of add-ons seems to be getting brought up again lately. One of the more active theme developers has started to charge for premium versions of their themes, leaving free basic versions still available on addons.mozilla.org. There are a couple of different issues with this, both of which many users are taking exception to. Apparently once I started writing about this I couldn’t stop so I’ve split this out into a couple of different posts to follow.

Add-on Developers, Get the News you Crave

Fri, 16 May 2008 17:23:51 +0000

Being an add-on developer can be hard work. So many different places to look for information about releases, new features and changes to the platform. How can you be expected to keep up with all this?

Well starting next week hopefully we’ll be taking a big step in the right direction. Mozilla are launching about:addons, a newsletter dedicated to getting add-on developers all the important information they need. There will be announcements about when to check your add-ons against new releases of applications, new features added to addons.mozilla.org, plans for the future that you can get involved with and early warning of API changes.

Extension Authors, Say Hi to McCoy

Mon, 17 Sep 2007 16:10:36 +0000

I know all you extension authors out there have been understandably miffed at the add-on update security bits landing before you could do anything about it, so I’ve pushed hard and we can now make an early version of McCoy available.

McCoy is the tool to use if you are hosting your own add-ons and for whatever reason cannot use SSL to secure the updates. If you haven’t yet heard about the new security restrictions that will be in Firefox 3 or you don’t quite understand them yet then why not skip on over to the vastly improved add-on updates documentation and take particular note of the security section.

Add-on Security Restrictions Landed

Mon, 03 Sep 2007 23:49:14 +0000

I have just checked in Bug 378216, and wanted to give a quick heads up on it.

What this means is that we are now enforcing a security restriction on all add-ons. To be specific, if an add-on does not provide a secure method of auto-updating then by default Firefox will refuse to install the add-on. If you have add-ons already installed that are insecure in this way then they will be automatically disabled.

Practice what you Preach

Sun, 19 Aug 2007 17:47:08 +0000

One of the main parts of my work for Mozilla at the moment is about securing add-on updates. The spec is now pretty near complete and the implementation is also pretty much complete so hopefully we can start pushing out the necessary tools to add-on authors real soon then land the work shortly after.

Of course it wouldn’t be right for me to push this out without first making my own extensions comply with the new requirements. So today I am rolling out updates to all of them, mostly just changing the update url to an SSL one, though a couple of the extensions (Nightly Tester Tools and /Find Bar/) have some additional updates.

The Wonder of Stats (Or where did all my users go!)

Fri, 20 Jul 2007 20:08:19 +0000

For some time now I’ve promised myself that I’d sort out a simple system to view stats about how many people are using my extensions. The idea is a simple one, on a daily basis Firefox (or whatever app) will ping my site checking for an update for the extension. Counting the number of checks in a day gives you a rough idea of the number of users. You can’t take the numbers literally of course but as ballpark figures go it’s probably not bad.

Securing Add-on Updates

Sun, 01 Jul 2007 00:00:00 +0000

Since the disclosure of potential vulnerabilities in the way Firefox (and other Mozilla applications) automatically update your add-ons we have been discussing how to tighten up the system in a way that is hopefully unnoticeable to users and not much extra work for add-on authors.

After a process of listening to authors on the newsgroups, forums and by email we now have a rough proposal of what changes we are looking to make. There’s still a few minor details to be ironed out of course. This is mainly of interest to add-on authors since there is an impact depending on how you host your updates. I’ve started threads on the newsgroup and forums so if you want to discuss the proposal there then that’d be good. I’d prefer it if you didn’t edit the main page of the wiki but feel free to stick small comments onto the discussion page.

Add-on Authors? Do you host your own?

Fri, 15 Jun 2007 23:11:33 +0000

We’re looking at the situation of automatic updates for add-ons and whether or not tightening up the security of such updates is a good idea or not (this is one good reason why it could be). After some initial talking I would like to get a little feedback from the add-on authors out there who host their add-ons on their own websites and not on addons.mozilla.org. Are you such a person? If so then please take a few moments to check out the thread in the forums or on the newsgroup and take a few moments to answer my questions.