Tag: addons

Moar xpcom docs!

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.

Secondly I finally sat down and put some hard graft into my rewrite of the project. Some time ago I decided on what extra information I could easily find out automatically and wrote the new code to shove it all into a database. It took till this weekend for me to actually write the web front-end to it. Despite appearances it is actually a complete rewrite. Previously I was using hand-rolled database access code in php. The new version is based on Django which is apparently what all the cool kids are using these days. I was for the most part pleasantly surprised by Django, it makes quite a lot of things significantly easier, but it does suffer from the problem that most object mappers do, it never quite does exactly what you want (or expect). Still I’ve no doubt despite the teething problems I found I have got further like this than I would have by hand. Pro-tip to those thinking of using it, don’t trust it to be right when it tells you what line of a template is causing an error.

Not everything is implemented yet, and I’m sure there are a few bugs laying around to find, but you can take a sneak peek at it. This is what is new:

  • Lists components as well as interfaces
  • Shows what operating systems interfaces are available on (watch out, this can and does vary with the version of Firefox)
  • Shows what components implement a particular interface (again, can and does change with the Firefox version)
  • Shows what interfaces a component implements and for which platform (ditto, our platform is complicated ok?)

There is actually a lot more potential information that could go into the database, including listing for multiple applications, but I think the UI will probably not develop that much further, the additional information would just make things far to complicated to understand.

Farewell contents.rdf

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.

What does this mean?

Chances are not a lot. If you are an add-on developer then look in your add-on’s source code. Is there a chrome.manifest file there? If so then you don’t need to do anything, you are already using the modern method of chrome registration. If not then look for contents.rdf files. If you don’t have any then you just have an odd add-on with no chrome.

How do I cope?

If your add-on actually doesn’t have a chrome.manifest file and needs one then you need to do one of two things. One option is simply to read the documentation on chrome.manifest and learn how to replicate what you have in the contents.rdf files into the manifest. Another is to install your add-on into a toolkit application since Gecko 1.8. You’ll find that when it installs it it also creates a chrome.manifest file for you from your contents.rdf files. Just copy it.

If you really need to support both an old version of an application (before Gecko 1.8, or not toolkit based) and a new version (Gecko 1.9.2 or newer) then you will need to keep both contents.rdf and chrome.manifest, replicating the information across the two.

When does this happen?

I have just landed the patch that removed support so trunk nightlies from tomorrow (12th June) should be affected.

Improving the add-on install experience

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.

In Firefox 3.0 we introduced a small feature to try to alleviate a little of this. After restarting Firefox the user would be shown new add-ons that had been installed so they could configure them. It also provided a little consistency across the restart which was normally done from the add-ons manager.

The current post-install display
The current post-install display

This UI had the additional small benefit that it would also display when other applications installed extensions into Firefox without the user’s knowledge. However as a post-install experience it really hasn’t worked out all that well for a few reasons:

  • It’s invasive. It pops up in front of the user after the restart and they feel the need to close it before doing anything else. This makes it almost as bad as some of the first run experiences provided by extensions.
  • It’s confusing. It can be pretty difficult to identify just what add-ons have been installed especially when the list is long.
  • It provides no next steps. Although if you click on the new add-ons you might get a chance to configure it, it doesn’t actually help push the user in any direction.

We’ve been thinking about ways to improve this for a while and there are a few different ideas floating around. I’d like to float one of them here and see what people think. The goal is both to let users know that new add-ons have been installed and let the add-on help the user move forward without needing to show popup dialogs or inundate the user with a webpage per add-on. It also needs to work in applications that aren’t Firefox. Excuse the poor mock-up, my UI skills aren’t all that hot.

Proposed first run experience
Proposed first run experience

The idea is that in Firefox this would display in the webpage content area. It might display immediately after startup, or it might be better to use an alert to tell the user new add-ons are there and then display it when they click on the alert. Other applications can open this in a new window or wherever they wish.

It’s designed to be clear exactly what has been installed and give the user things to do with those items. Preferences at a bare minimum, but the yellow highlighted areas are the interesting bit. Those represent overlay points where the add-on can put whatever UI it likes. This might be a simple message to tell the user how to get started. It might be a few of the most common settings, maybe a login box. It might be a button to launch further UI like a wizard.

I think, even if this were to open immediately in Firefox, this addresses the main deficiencies of what we currently do. I’d hope that many add-on developers could then stop their custom first-run stuff and instead just use this, but I know there are lots of different needs out there so I’d like to hear where this doesn’t work to see if we can accommodate.

Letting add-ons perform work during install and uninstall

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:

  • Add-ons will be able to provide code to run when their add-on is installed, uninstalled, disabled, enabled or upgraded.
  • Add-ons will be able to provide a list of files in the profile folder and preferences to be removed when the add-on is uninstalled.

There are a few restrictions so if you are interested check out the full specification and let me know what you think. There’s still room for change, but I think the proposal provides real benefits for add-on developers as it stands.

What’s up with the extension manager?

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.

The main reason for this is simply the delayed launch of Firefox 3.5 (previously 3.1). At the time I was working on the plan I was anticipating 3.1 to release fairly quickly, or at least my part in its release would have trailed off. That didn’t happen and, as is the nature of these things, there hasn’t really been any time for me to work on the kind of rolling improvements the roadmap talks about while we’re trying to ship the next big release of a product. Blockers and bigger ticket items will unfortunately always get in the way.

Releases come in bursts though. My work on 3.5 is basically done and the next big release won’t be for at least half a year, maybe longer. Once I’ve taken a small break I hope to start making progress on the extension manager work again. I think I’m going to work things a little differently. The first thing I will try to do is come up with some good specifications for all of the features. The idea is that if we have good consensus on the details of each then it’ll be easier to get more people working on them in parallel.

Getting a head start on this I’m going to make more public the specification for add-on install hooks…

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

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

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?

I’ve written a small extension that helps test these background tasks. It is fairly simple, just gives you a menu option to trigger one of the background checks. It saves delving through preferences and changing the timers to run faster. Most users shouldn’t use it but I figure it is useful for other developers and add-on authors so I’ve put it in the sandbox on AMO and you can go download it from there.

Brussels bound

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.

I’m not giving any presentations however if you want to grab me to talk about extension development, XULRunner applications or anything else then feel free. Hopefully the lack of beard won’t leave me too unrecognisable.

Updated Interface lists

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.

I have for the time being had to disable caching in the application, it was eating up literally gigabytes of disk space on my web server and not giving all that much of a speed-up.