Firefox is Mozilla main and most used product, and of course if you want to create an extension Firefox is your main target. But why limit yourself to Firefox?
You may not know it, but if your extension isn’t too complex, and it doesn’t rely on Firefox-specific technologies, it will probably be compatible with SeaMonkey out of the box, all you have to do is to register SeaMonkey in the install.rdf file, with this code:

<em:targetApplication>
  <RDF:Description>
    <em:id>{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}</em:id>
    <em:minVersion>min version</em:minVersion>
    <em:maxVersion>max version</em:maxVersion>
  </RDF:Description>
</em:targetApplication>

so that all of the SeaMonkey users can benefit from your extension, installing it painlessly and receiving the automatic updates from a.m.o. With the rapid release process is even easier, because the gecko version on Firefox and SeaMonkey is strictly related, so you can discover easily which are the correct min and max version numbers.
Everything you have to do is to loose 5 minutes of your time to try your extension on SeaMonkey, that’s all.

Not all of the extensions work out of the box, though. I’m not an extension developer and I don’t know anything about xul or js (so don’t ask me for help), but I’ve discovered that in some cases the compatibility with SeaMonkey is just one line of code far.
If you have to register some component (e.g. a stylesheet) in chrome.manifest and you have a line similar to this:

style chrome://browser/content/browser.xul chrome://myext/skin/mystyle.css

everything you have to do to make it compatible with SeaMonkey is to add this other line in the same file:

style chrome://navigator/content/navigator.xul chrome://myext/skin/mystyle.css

this is the case of extensions like xclear, Reader and Readability.

In some cases this is not enough, and then I don’t know how to help you, but I want to ask you all, extension developers, to spend these 5 minutes to install SeaMonkey and check these two easy things.

In this way we’ll all win: SeaMonkey users will be able to benefit the functions of your extension, and you’ll get hundreds of possible new users.

From now on a valid language code may be used instead of ‘selected’ and ‘all’.
If the language code is invalid or there is no translation available, an error message appears.

Example: http://www.babelzilla.org/wts/download/locale/de/skipped/5136

This will download the “de” (German)  locale and skip all missing strings.

You can now use this default URL:

http://www.babelzilla.org/wts/download/locale/

The download requires 3 parameters:

The first parameter: Type of the download. You can download all or the selected locales

Allowed values:

• selected
• all

The second parameter: Handling of untranslated strings

Allowed values:

• replaced
• skipped
• blank

Last but not least, third parameter is:

• The id of the extension

as set by the WTS on submission

Example:

http://www.babelzilla.org/wts/download/locale/all/skipped/5136

Enjoy!

Please tell us if you find it useful and if you need more things of this kind.

Dear translators and extension developers, we are glad to give you back access to BabelZilla services and want to apologize for the terribly long downtime.  Reason is: our server was hit by a DoS attack and unfortunately also used to attack other servers. Our provider reacted very fast and stopped all traffic from and to our main IP. During the next days we tried to find the hole and checked the server logs. We found the attack in the logs and removed the vulnerable script. (No, it was not the WTS )
To be on the safe side, we decided to set up the server from scratch.
Currently we still have problems with tar.gz files. The created files are OK, but the downloaded files are corrupt.

Our Tech Admin tried his best to restore everything as soon as possible,  so BabelZilla is available again. You are welcome to use it again, please let us know if some unusual behavior occurs when using the WTS — I mean anything else than the usual familiar limitations
Sorry again for this major failure and thank you for your patience.

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.

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

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