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.