Firebug 1.2 final is set to be released sometime within the next week or two which means that our goals for Firebug 1.3 need to be pretty clear at this point. Last week the Firebug Working Group convened at Google to discuss the goals for the upcoming release. In taking a step back and looking at what was most important one thing was quite obvious: The stability and performance of Firebug needs to be improved.
Unfortunately we’re in a very difficult situation. There are, approximately, three developers who’ve done any sort of serious bug fixing on the internals of Firebug. One is John J. Barton (of IBM – primarily responsible for the 1.1 and 1.2 release of Firebug) and the other is Jan Odvarko (of Mozilla – part of the new Firebug team). Unfortunately the primary source of information lies in Joe Hewitt (the original creator of Firebug), who is quite incommunicado these days.
There are a few areas in which we (and, specifically, the Mozilla Firebug team) need to work in order to gain a solid footing.
Improve the knowledge of Firebug that we have.
Right now information about Firebug internals are quite limited. Not only does there need to be some serious overviews of what’s there but inline documentation needs to be improved as well. It can be incredibly hard to hack your way around some aspects of the code base, especially when it isn’t obvious how something works.
We’re going to be working two-fold in this area: To start Rob Campbell and I will be working on some Firebug extensions in order to get a better feel for the code base – and secondly we will, as we go, write up tutorials and documentation for what we find.
Jan has already written up an excellent series of tutorials that explain how to construct Firebug extensions. They’re, already, quite valuable.
Build a runnable set of test cases to prevent regressions.
The unit testing (or, really, any testing) situation in Firebug is quite abysmal. Features have gotten accidentally removed from releases simply because they weren’t immediately apparent that they existed. We need to make sure of two things: 1) That existing features don’t break or get accidentally removed and 2) That a good enough coverage of the internals is in place to support future development.
Track the state of Firebug performance.
There’s, effectively, no picture of how Firebug is currently performing (or, more accurately, hindering performance) in Firefox. If we want to improve the quality of the code we have to have a clear picture of which areas are problematic. This is one area in which Mozilla’s resources can be especially beneficial.
We want to create some builds of Firefox that have Firebug on in various states. For example: Firebug installed (but disabled), Firebug enabled, Firebug with console enabled, Firebug with debugger enabled, Firebug with network monitoring enabled, etc. With all these permutations we’ll be able to get an exact number for how much overhead current Firebug code is providing and where we can start to make necessary improvements.
Audit and Improve.
Finally, once we have some documentation about the structure, a test suite running, and nightly performance numbers being generated we can really start to dig in and make improvements. It’s going to be slow-going at first but laying this groundwork will make for an effective use of our time (increasing the likelihood that other people will be able to help contribute to the codebase, as well). If we can have a stable and fast Firebug 1.3 ready in time for Firefox 3.1 (which is due out this fall/winter) then I feel like we will have made some good headway and started to serve our purpose well.