Chapter 4: Dynamic Development

Firefox’s support for dynamic extension development is the single most useful feature for developers. This capability allows you to work on your extension and see the results in real time! Not only does this reduce your development time, but it makes debugging even easier than before.

How does this feature work? Well, we can thank the chrome manifest that we created in chapter 2. There are a few steps we have to take to "enable" dynamic development for our extension, but first I’d like to present you with some sound advice.

A Word of Warning

Extension development can be a somewhat dangerous thing, especially when working with XUL overlay files. I highly recommend that you avoid testing and developing your extensions in the same profile that you normally use for web surfing. In other words, you should create a brand new profile in which you do all of your development and testing. This will prevent you from losing key browser data: stored passwords, cookies, bookmarks, and any other stuff you would hate to lose.

To learn more about how profiles work in Firefox, consult either the tutorial I offer on the subject, or the official profile documentation. Creating and using a new profile is an easy task, and it will save you a great deal of headache down the road.

How to Develop Dynamically

The majority of our work has already been completed in the chrome manifest, even though you may not have realized what we were doing at the time. Now all that we need is a file to point Firefox to our extension’s location on our hard drive. We will do so through the use of a "pointer" file.

First, create a text file anywhere on your computer and give it the same name as the <em:id> we used in the install manifest. For this tutorial, the value we chose was tuttoolbar@borngeek.com; so our text file should use that exact same name. Unfortunately for Windows users, the ".com" file extension usually indicates an executable. In our case, it will just be a simple text file. If you would like to keep the ".com" portion out of the filename for now you may do so; just remember to update the <em:id> value in the install manifest to match your altered name (and remember to change it back when you package your extension).

Inside of this file we will place exactly one line of text: the absolute path to the folder where your extension is stored (that is, the folder that contains your install.rdf and chrome.manifest files). In my case, this tutorial extension is stored in the following location on my computer:

C:\Born Geek\TutToolbar

You should clearly use the path to the extension on your computer, unless the path happens to exactly match the one above (and I doubt that it does). After typing the absolute path to your extension, save the file.

We now must move this file to our development profile’s folder. The backing up your information article discusses exactly how to locate your profile folder. Once you find where the profile is located, place the pointer file we just created in the extensions folder within the profile folder. Here is how my sample profile file structure looks (trimmed down for brevity’s sake):

tl5wlpz3.Sandbox/
 |-- bookmarkbackups/
 |-- chrome/
 +-- extensions/
      |-- tuttoolbar@borngeek.com
      +-- (... other files and folders ...)

As you can see from the name of my profile’s top folder, I use a "Sandbox" profile to do my extension development. Once the pointer file you created has been placed in the proper location, start Firefox, making sure that you use your development profile (again the profile documentation mentioned earlier will show you how to do this). If you have done everything right up until this point, you should see your toolbar, in all of its un-skinned glory!

Useful Browser Settings

In order to prevent several dynamic development annoyances, we need to toggle a few rather obscure browser settings. They can all be set through the about:config interface. A few of the more interesting ones have been detailed below, but there are others you should consider. This article at MDN contains a larger list of preferences to consider. Note that some of these preferences may not exist by default, and may have to be created (which you can do by right clicking in about:config, and selecting the New menu option).

javascript.options.showInConsole
When set to true, any errors or warnings that appear in your extension’s chrome files will be sent to the JavaScript console (which I’ll discuss again in chapter 8). This is a very handy way to track down problems.
nglayout.debug.disable_xul_cache
When set to true, disables the XUL cache, allowing you to make changes to windows and dialogs without having to restart. Note that any changes to overlays will still require a restart of the browser.
nglayout.debug.disable_xul_fastload
(Firefox 4.0+ Only) Set this to true to prevent some weird fast-load cache problems with dynamic development. Bug 531886 has more information on this setting.
javascript.options.strict
When set to true, the JavaScript parser within Firefox will be placed into strict mode, placing tighter restraints on your extension’s code. This helps to improve your code’s integrity and makes it easier to track down subtle code problems.

The Development Cycle

So now that we have enabled dynamic extension development, how do we use it? The process is actually very simple:

  1. Edit your extension files.
  2. Either reopen the window(s) that the modified files apply to, or use the Reload Chrome feature of the Extension Developer’s Extension.

There are two special cases you should be aware of:

  • If you change the chrome.manifest file, you will have to restart Firefox (this file only gets parsed on startup).
  • If you change the install.rdf file, you will have to alter the modified time of the folder that your "pointer file" points to. In Linux you can simply use the touch command to do this. In Windows, it’s somewhat more difficult (unless you have the Cygwin tools installed, in which case you can simply use the touch command). One simple way to handle this case is to create a new folder within the extension’s top level folder, then delete that new folder.

As you can already see, this will be an incredibly handy tool as we develop and debug our extension. Now let’s make this ugly toolbar we’ve created look a little better!