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.

After a long time I have some news for the WTS.
The next WTS will have a version control system.

Because I know that you’re curious here are some screenshots from the new system:

Version Control on the WTS!

Viewing Logs

Showing File Content using GesHi Syntax Highlighter

'Blame': Viewing Who Did What

Viewing File Diffs

Viewing More Diffs

I love movies , therefore I’d like to write about a few scenes of movies I love and which inspired me!

Do you remember Marilyn Monroe when sang “Diamonds Are A Girl’s Best Friends”?

Well, girls prefer diamonds but they don’t develop extensions for Mozilla products, or at least girls programming extensions aren’t so much (sob!!)

OK, now I’ll try to be “serious”: I love also Fantastic Four, probably not exactly the same who you love, but they are however special friends with who I’ve built solid friendship during the period of programming extensions (a long time)!

I know some extension developer losses much time to find information that can be easily (???) found using my best friends.

The first I encountered was DOM Inspector.

This one help me to dig inside DOM nodes for chrome (and normal pages!!) in a user friendly way, it simply speedup my XPCOM learning curve.

Many developers simply ignore DOM Inspector value; they should write thousand times on blackboard:

I will use DOM Inspector before ask to anyone
I will use DOM Inspector before ask to anyone
…

My second friend is Mozilla lxr, the source cross reference.

For many years I used “find in files” utilities to browse source code but now I have a hyperlinked way to find snippets of code.

Why lxr is so magic for me?

I can search source code and navigate using links to functions, variables, classes and any type of source code.

Try it and you will discover a new way to study source code for complex applications!

My friend (and I hope your) XUL planet is the well know APIs and tutorials site about XUL.

Nothing to say, writing extensions without xul planet is equivalent to drive a car in dark of the night without lights.

Last but not least: Bugzilla.

Have you never read “In case of emergency, break glass”?

Well in case of emergency Bugzilla is a valuable tool, you can search if someone has already encountered your problem and if it’s a bug or simply your mind is bugged .

Honestly I don’t know how to really use Bugzilla, I’m unable to use the incredible powerful search engine but this is related to my stupidity .

Mr. Fantastic: lxr
Invisible Woman: DOM Inspector
The Thing: XUL planet
The Human Torch: Bugzilla

Who are your Mozilla devel best friends?

Tell me so they can became my new best friends