• Firebug 1.3.0b2 is available on getfirebug.com
• Discussed Honza’s awesome improvements to the Net panel
• Discussed John Resig’s further efforts on FireUnit and NetUnit integration
• Starting to push new code to 1.4 branch, 1.3 for bugfixes and cleanup only.

That’s the short version.

The longer version includes some good discussion about the net panel improvements, including some ideas for color improvements and drawing MozAfterPaint events on top of time-lines. We’re starting to see some additional load events super-imposed on the network traffic now, so the term “Net panel” is probably going to be replaced with something like, Construction Timeline in a later version. I don’t know what that name will be yet.

Resig’s improvements to FireUnit include a test-runner mechanism for running through a set of chrome files containing unittests. He’s also making good progress on integrating Honza’s NetUnit tests which will include the httpd.js server for hosting locally stored tests. We’re getting that much closer to having a usable unittest solution.

That’s not to say that we have full unittest coverage yet. I spent a couple of days messing around last week trying to write some Script panel unittests but ended up scrapping them because I coded around the thing I was trying to test. It was educational at least. I’ve moved back to working on rewriting some of the packaging tools so we can have a saner, cross-platform mechanism for building the extension and stripping out all the debugging and tracing code. Hint: It will probably be written in a language named for a certain non-venomous snake.

Not mentioned in the bullets, John Barton has moved Chromebug into the google code repository we’re using for Firebug. Feel free to check it out and give it a whirl. We should be much closer to having Chromebug in a usable state where Firefox and extension developers can start using it.

Oh, and one last thing: For all you testers running nightlies, we’re going to bump the MaxVersion on Firebug to 3.1 so you can start re-enabling your compatibility checks. Note that Firebug 1.3 on Firefox 3.1 will be considered experimental and useful for testing purposes only. We know there are problems, but we need to track them down and fix them in Firebug 1.4. If you encounter a problem, do a search in our Issues database and if you don’t find it, file it!

First, there are a couple of caveats about Chromebug. It’s still in an experimental state. Some parts work well, like the inspection of a chrome window’s DOM tree and CSS. Other parts are a little flakey or down-right broken. As of right now, the default build instructions will attach you to a 1.3 version of Firebug which has some improvements to handling large script files but is also somewhat broken. It should improve shortly.

So, with that out of the way, I’ll run through a quick Chromebug setup and install. The instructions are on the sourceforge page for Fireclipse, a plugin for Eclipse that adds some debugging capabilities for Firefox and/or JavaScript.

Step 1. From a suitable directory on your computer, check out the chromebug sourcecode from svn. There are external svn references to include two other add-ons, chromelist and firebug. These will get checked out as well.

Step 2. Create a new profile for Firefox using the Profile Manager. I called mine “Chromebug”. Make sure you start Firefox with this new profile to finish the creation process.

Step 2a. Make note of the location of this new profile. You’ll need the full path for the following step. On Windows, this would typically be in “C:\Documents and Settings\%USERNAME%\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.Chromebug\”. Replace %USERNAME% with your username, and xxxxxxxxxx with some randomly generated string. Just look for *.Chromebug in that directory. You will need this for the “install.dir” property in step 4 below.

Step 3. In a console (or terminal window), cd to the chromebug directory you checked out earlier. E.g., cd ~/Projects/fireclipse/extensions/chromebug

Step 4. Create a local.properties file using your favorite text editor in this directory. Add the following properties to it (each property should be on a single line, regardless of how this blog breaks it up):

Step 5. Create links to the chromebug extensions. This can be most-easily accomplished using the build.xml file provided in the fireclipse/extensions/chromebug directory and the Java build utility ant. If you don’t have ant installed, you can do this manually as per the instructions in the included readme file. It’s standard extension development linkage.

And now you should be ready to fire it up using (on windows):

Replace firefox.exe with firefox-bin on unixey OSes. You should see two windows open. One, a smaller window with the title Chromebug, the other, a standard browser window. Before you get too excited and jump in, you should quit the application and restart it (again, using the above command) to make sure the chrome files get registered properly. Now you should be ready to play!

Please keep in mind that Chromebug is experimental. There’s a lot of code in there and not all of it’s working. We are interested in getting more people using it and reporting problems though so check it out, and if you encounter any problems, feel free to come to #firebug in irc.mozilla.org and ask questions. You may have better luck using Firebug 1.2 instead of 1.3 currently, but I haven’t tested that myself. It should be a matter of changing the firebug.dir property in the local.properties file from step 5 above.

I’d like to thank John Barton for patiently walking me through the above and giving me a walkthrough of the code itself. It’s incredibly cool stuff and I’d love to see it become part of the standard arsenal of extension development tools as well as part of the toolkit for developing firefox front end features. In the coming weeks, I’ll post follow-ups on the state of chromebug and what you can do with it.

Happy debugging!