I use the Automator application that is part of all default Mac OS installations. This is a tool that allows you to create automated tasks, as you might have guessed. Then I do something like this:

1. Open Automator.
2. Choose the Application template.
3. From the long list in the second column, double click on Run Shell Script. This will add a box on the main panel, with a text input.
4. Enter this: /Applications/${APPLICATION}.app/Contents/MacOS/firefox-bin -P ${PROFILE} > /dev/null &
5. Replace ${APPLICATION} with the name of the application you want to run (Firefox, Aurora, Nightly, etc.). Replace ${PROFILE} with the name of the profile you want to run, or leave it blank to open the profile manager.
6. (Optional) Replace /dev/null with a file path to save the console output to a file.
7. Save the application to the Desktop.

That’s it. You now have a Windows-style shortcut that opens a specific application and profile combination. Repeat as necessary and you’ll have all the shortcuts you need, which you can open in parallel (except opening the same profile with multiple applications, which would be a bad idea). My desktop has a matrix of profiles and applications that are very convenient for my testing needs. You may want to have them in the dock or elsewhere, but that’s a matter of preference. You can also change their icon, which is not really worthwhile IMO.

You can copy and paste applications and then open them in Automator to edit their parameters. You need to open Automator and then choose the Open option, there’s no contextual edit option, which is a bit of an annoyance.

If anybody has a different system to deal with this on Mac OS, I’d love to hear it.

Firefox 4 for Add-on Developers

For now, this is a pretty good reference if you want to start supporting the Firefox 4 betas in your add-ons. I’ll be elaborating on this subject through the following weeks, in the Add-ons Blog.

I’ve been an extension developer for a long time, and I like to think that developing extensions is actually quite easy. Maybe it has to do with my C++/Java background, where setting up a development environment is much more involved than using a text editor and zipping some files together.
That doesn’t negate the fact that the Mozilla add-ons platform is old, and showing its age. There are a number of problems with it that make it hard to take the first steps into add-on development, and it’s amazing how little has been done to solve them over the past years. These are the top 3 in my mind:

• Extensions can’t be installed or uninstalled without a browser restart.
  • That’s bug 256509. Can it be fixed? Probably, but it would take a major development effort.
• The documentation about extension development is incomplete or outdated.
  • I’m working on this in the XUL School project, to be finished soon.
• Getting started with a basic “hello world” extension is too much effort: install.rdf, chrome.manifest, chrome JAR, content, skin, locale, defaults, OMG!

The last point is the one I want to tackle in this post. There’s a ridiculous amount of boilerplate, redundant coding to do even for the most basic of add-ons, specially if you’re making an extension that should be skinable and localizable. These are the specific problems I’ve identified:

• There are two manifest files: install.rdf and chrome.manifest, in completely different formats.
• They are both defined in relatively obscure formats. The install.rdf file is one of the very few places where RDF is still used in Firefox. Sticking to a dying format (at least in this context) is a very bad idea.
• The default chrome structure (with content, locale, skin, etc.) is too bureaucratic and inflexible, and almost completely redundant. Most add-ons have exactly the same structure, and having to define it every single time is unnecessary.

I think we can reimagine add-on packaging in way that simple tasks can be performed in the simplest of ways, and so that it can scale to be as fine-tuned as it is today. So here are my ideas.#1 Merge install.rdf and chrome.manifest into a single file. What format should be used? I think JSON is as good as any other, and Mozilla already includes a native and very fast JSON parser. This manifest file could also match the package.json manifests being used for Jetpacks. package.json is actually a pretty good name for the manifest file. Perhaps the same standard can be use for Jetpacks and other add-ons?

#2 Default to the root extension directory for chrome URLs in order to minimize chrome.manifest declarations. This means that a hello world extension could have this structure:

• helloworld.xpi2
  • package.json
  • overlay.xul
  • overlay.js
  • overlay.dtd

And the manifest file would be something like:

{
  id : “helloworld@xulforge.com”,
  name : “Hello World!”,  
  type: “2”
  compatibility :    
    { id : “{ec8030f7-c20a-464f-9b0e-13a3a9e97384}”,
      minVersion : “3.5”,
      maxVersion : “3.6.*”},     
  domain: “helloworldchrome”,
  overlays:      
    { source : “chrome://helloworldchrome/content/overlay.xul”,
      target : “chrome://browser/content/browser.xul”}
}

(Note: ‘compatibility’ and ‘overlays’ can be arrays when there’s more than one item. And the ‘domain’ value is a general declaration of the chrome domain.)

In this new system, you would be able to have all of your chrome files in the root directory and have no need for chrome directives other than declaring your main overlay. Also, in your root directory you can have a locale or skin folder that the system would know how to handle without any changes to the manifest. If a file isn’t found in the locale or skin folder, then the system falls back to the root directory as a last resource. Of course it would still be possible to declare specific locations for content, locale and skin in the manifest, in order to allow the “old style” to be used.

What about other special locations?

• platform and components will continue to have their special meanings.
• JSM files can be handled just the same as chrome files, except that they use resource:// instead of chrome://.
• The default preferences file should also be moved to the root and have a predetermined name, like defaultPrefs.js.

#3 Installing the package. When you install an XPI file, the file is unpacked in your profile directory. It is common (but not mandatory) practice for chrome files to be packed in a JAR file, which remains packed after installation. According to recent discussions about add-on performance, it’s more efficient to keep files packed together. Instead of requiring authors to use the internal JAR approach, I think it makes more sense to require authors *not* to use JARs, and then keep the packed XPI in the profile on installation. Files that need to be extracted, like the manifest (maybe) and binary components (according to this) can be extracted upon installation. This way it’s up to the platform and not the developer to look after performance.That’s it. Given that this new packaging system would be backwards-incompatible with the current one, it might make sense to change the file extension to something like XPI2, in order to make a clearer distinction between the 2. However it should suffice to look for the manifest file in order to identify the system in use.
How hard is this to implement? I think #1 and #3 are fairly simple to implement. #2 is the one that may present a bigger challenge, since the chrome URL system is something that runs deep in the Mozilla code, and changing its file location rules could cause breakage or vulnerabilities in non-add-on code. It might also be possible to limit the scope of these changes to add-ons only, but again, that may require lots of work. I’d love to hear the opinions of those who work on this part of the platform.

Some may wonder how does Jetpack fit into this whole idea. Well, Jetpack is a different platform, and it may very well replace traditional add-ons in the long term, but we’re still a long ways to go. We shouldn’t see Jetpack as some kind of competition, but as a lesson in what we can do better. If we improve add-on packaging to be closer to Jetpack packaging (I think this would be), then it’s a win for both, because it’ll make it less painful for developers to choose and switch between either platform.

I’d love to hear what experienced developers (both add-on and platform) think about this. I think there’s a real gain for novice developers in this if we were to implement it. I intentionally left out some details for brevity, but I’ll be happy to discuss them in the comments. Thanks for reading.

On Thursday, the update queue had about 80 add-on updates in line to be reviewed. This is a short as it’s been for a very long time. Today it stands close to 200 updates, and will continue to grow in the following couple of weeks. All authors are now rushing out updates because they just realized Firefox 3.6 is out.

Well, now it’s up to the editor team to catch up. It’ll take a while, I think. Authors that decided to update after the 3.6 release will now have to wait. It’s bad for everyone, and the result of bad communication. That’s something we’ll need to work on.

This project is a set of skins for the Personas extension. Personas is a new approach to developing themes for Firefox and other Mozilla apps. Creating a skin is pretty simple: all you need is a header image and a footer image. Creating a good one is a little harder; you’ll need to fill a very, very large image area, while at the same time keeping in mind that only a tiny fraction of the image will be visible in the majority of browsers. Patterns and other artificial designs are probably easier, but mine are just extracts from my large photo collection, so it’s trickier.

I have a list of the skins I’ve created in the project page, with explanations on why I chose the pictures. So far my designs are doing pretty well, with a few hundred active daily users at this time. You can see the user counts in my designer page.

My skins were all created using The Gimp, and the pictures were taken with 2 different models of the Canon PowerShot (I upgraded recently). Artistic feedback is greatly appreciated.

Anyway, at the time we were pretty excited about it, and we spent a great deal of time and effort making Fire.fm a sure winner. And we won! We won the Best Music Add-on category, and I think we weren’t allowed to win in others, because I think we should have won the general competition as well . Needless to say, we were super happy with this, and we have been actively maintaining the add-on in our spare time.

Fire.fm is, in a nutshell, a Last.fm radio player. It used to be a very easy way to tune into Last.fm radio without having to be on top of the website all day long. Our users loved it, and shortly we were in the AMO Recommended List.

Sadly, Last.fm cut off their free radio service to most of the world shortly afterward, so at least I lost a lot of the motivation I initially had to continue making it grow. Still, I don’t want to abandon a project that still has much to be fixed, so I’ll certainly won’t quit until all the annoying bugs are solved. Most users have a very smooth experience with Fire.fm, but there are a few unlucky ones that have some serious problems, like not being able to listen to stations at all… New features in Fire.fm are probably going to be very rare from version 1.2.3 and later.

Xulforge was already in my mind when we began working on Fire.fm, so I always kinda saw it as a Xulforge project. Xulforge was put on hold until very recently, so it feels weird trying to associate the two. I’ll keep Fire.fm in my project list, though, because I it was one of my first independent projects, and also because it has been very successful and I’m very proud of it.

Fire.fm is open source, BSD-licensed (more on that in another post). So, if you want to take a look into our code, you’re more than welcome. See the Fire.fm Sourceforge Project Page for more information.

Fire.fm Logo