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.
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.
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.
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.