It’s time to exorcise contents.rdf

It’s time to exorcise contents.rdf

What are contents.rdf files?

Junk from a bygone era. When writing a Mozilla extension you need to tell the application where and what your extension’s files are. Since Firefox 1.5 (Gecko 1.8) it’s been a simple matter of writing a chrome.manifest file, but before that there were contents.rdf files. You needed a contents.rdf file for your overlays and another one for each locale. An example:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

  <RDF:Seq about="urn:mozilla:package:root">
      <RDF:li resource="urn:mozilla:package:myext"/>
  </RDF:Seq>

  <RDF:Description about="urn:mozilla:package:myext" chrome:name="myext"/>

  <RDF:Seq about="urn:mozilla:overlays">
   <RDF:li resource="chrome://browser/content/browser.xul"/>
   <RDF:li resource="chrome://navigator/content/navigator.xul"/>
  </RDF:Seq>

  <RDF:Seq about="chrome://navigator/content/navigator.xul">
    <RDF:li>chrome://myext/content/overlay.xul</RDF:li>
  </RDF:Seq>
  <RDF:Seq about="chrome://browser/content/browser.xul">
    <RDF:li>chrome://myext/content/overlay.xul</RDF:li>
  </RDF:Seq>
</RDF:RDF>

and for each locale, a different version of:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:chrome="http://www.mozilla.org/rdf/chrome#">

    <RDF:Seq about="urn:mozilla:locale:root">
        <RDF:li resource="urn:mozilla:locale:en-US"/>
    </RDF:Seq>

    <RDF:Description about="urn:mozilla:locale:en-US" chrome:name="en-US">
        <chrome:packages>
            <RDF:Seq about="urn:mozilla:locale:en-US:packages">
                <RDF:li resource="urn:mozilla:locale:en-US:myext"/>
            </RDF:Seq>
        </chrome:packages>
    </RDF:Description>
</RDF:RDF>

It’s a mess. These days you do the same thing in a chrome.manifest file with one line for each locale and overlay, instead of dozens and dozens of files of RDF gobbledygook all over the place.

Great. It was replaced 4 years ago…

Not quite. SeaMonkey 1.x still uses install.js scripts and this whole archaic system. Its engine is extremely out of date. If you want your extension to support SeaMonkey 1.x, you’ll need to write your own god-awful install script (what, do it automatically? you must be joking) and dozens of different contents.rdf files. Each locale will have its own contents.rdf and will probably scare your translators. It’s a mess that most extension developers don’t want to write or maintain, but… there is hope: SeaMonkey 2. After years of rewrites, the so-called “Toolkit Transition” brings the SeaMonkey code base into the modern world with support for all the sane extension stuffs you’re used to in other Mozilla applications. You can write one extension that works in both Firefox and SeaMonkey without having to do too much special. SeaMonkey 2 should be released soon, so we will finally be able to retire this kludge. There might be some other obscure application out there that still uses these, but I think it has almost entirely gone the way of the dodo at this point.

Why do I care?

Again, it’s a mess. It’s added complexity that is long since obsolete and hasn’t been recommended since Firefox 1.0. Furthermore, for Firefox 3.6 (Gecko 1.9.2) the entire functionality has been removed.

If you’re an extension developer:

If you’re still in the stone age and relying on this system for chrome registration in newer applications then you’ll need to switch to a chrome.manifest for your extension to work in Firefox 3.6 and later. It’s not hard. Firefox 1.5 or later will even make one for you if you install an old extension into it. You can leave it in to support really old applications and it won’t hurt anything if you’re also using a chrome.manifest, but eventually you’re going to want to clean it up and get with the program.

If you’re just stringing along your install.js and contents.rdf files for SeaMonkey 1.x support, then it’s time to start thinking about dropping it. SeaMonkey 1.1 is almost 3 years old now. SeaMonkey 2.0 will be out soon and it’s lightyears ahead of its predecessor in many areas. Many extension developers have already started dropping SeaMonkey 1.x support in favor of 2.0 and you’ll probably also want to do so at some point.

If you’re an extension user:

With various major upgrades and the death of install.js and contents.rdf, writing extensions for SeaMonkey is no longer ugly. More and more Firefox and Thunderbird extensions can be expected to gain SeaMonkey support in the future because developers won’t have to handle things too drastically differently anymore.

If you’re an extension translator:

If one of your localizations still has a contents.rdf file for you to “translate” (i.e. change all the instances of “en-US” to your locale’s ID), feel free to point the extension’s developer here. Translators were never intended to have to deal with these things in the first place. All it does is add confusion and a rather unneeded extra hoop to jump through.

<?xml version=”1.0″?>

<RDF:RDF xmlns:RDF=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:chrome=”http://www.mozilla.org/rdf/chrome#”>

<RDF:Seq about=”urn:mozilla:locale:root”>
<RDF:li resource=”urn:mozilla:locale:en-US”/>
</RDF:Seq>

<RDF:Description about=”urn:mozilla:locale:en-US” chrome:name=”en-US”>
<chrome:packages>
<RDF:Seq about=”urn:mozilla:locale:en-US:packages”>
<RDF:li resource=”urn:mozilla:locale:en-US:flagfox”/>
</RDF:Seq>
</chrome:packages>
</RDF:Description>
</RDF:RDF>

This entry was posted in Localization, Tech Room! and tagged , . Bookmark the permalink.