The final version of Firebug 1.2 has been released. The release should be up on the Mozilla Add-ons site today, but it’s also up on GetFirebug.com right now.

John J Barton and Jan Odvarko put a ton of work into this release (you may have noticed the rapid-fire series of beta releases last week – just trying to smooth out the rough edges).

There have been a number of improvements made (not to mention countless bug fixes). Some of the major points of this release include:

Firefox 3 support.

If you’ve been using the Firebug 1.2 betas you’re already on top of this. Now is a good time to verify the version of Firebug that you’re using. Go to Tools > Add-ons in Firefox and see what version of Firebug you’re running. If it’s anything other than 1.2.0bX (where X is a number 1-15) you’ll need to forcefully go to the above Firebug URLs and install the new version (the auto-update isn’t working for older versions). The most common report of Firebug problems has been related to running Firebug 1.1 in Firefox 3 – which is a mess (hence Firebug 1.2).

Quality Improvements.

The Script panel (the JavaScript debugger), the Net panel (network monitoring), and Console panel have all seen considerable updates. They’re all much more performant and have a huge number of bug fixes.

Specifically the Console panel has seen a number of security improvements. We’ll be discussing the specific nature of these changes once everyone has had enough time to upgrade to Firebug 1.2.

A list of all the bug fixes can be found in the full release notes.

Selective Panel Enablement.

This is the most drastic UI change of the release. It’s also a, seemingly, bizarre addition to the extension. When you now click Firebug for a site you’ll encounter an interface that looks something like this:

Some back story is needed in order to explain why the extension is now set up in this manner. These three panels (Console, Script, Net) have the potential to incur a great deal of overhead into any web sites that utilizes them. There are two pain points, in particular: The Mozilla JavaScript debugger and network monitoring.

The Mozilla JavaScript debugger is used in two ways in Firebug: First it is used in the Script panel (to debug JavaScript code, naturally), second it is used to figure out where JavaScript errors are coming from in the console. Network monitoring is, naturally, used for the Net panel.

Here’s the important point: The Mozilla JavaScript debugger and network monitoring are both global to Firefox not localized to a single window or tab. This means that when you enable a panel, such as the script panel, it will turn on the JavaScript debugger for all JavaScript code in Firefox.

Rob Campbell has run some initial numbers and has found that, simply, enabling the script panel anywhere in the browser immediately slows down all JavaScript execution by 25% – for all JavaScript on all tabs in the browser.

We don’t have solid numbers on the networking monitoring overhead yet but we imagine it to be much less, although still occurring on a global all-tabs scale which isn’t desirable.

The important question here is: What is being done to stop this?

First, it must become necessary to not incur any overhead when using the console panel. This is a ubiquitous part of Firebug and any global overhead presented by it must be removed. This can be done but not without some internal API changes to how Firefox handles and reports error messages. We hope to have something introduced in an upcoming version of Firefox so that we can compensate appropriately in Firebug.

Second, the JavaScript debugger must be improved. A number of bugs have been filed on this subject and we hope that some of them will make their way into upcoming versions of Firefox (Firebug will be able to immediately improve when that happens). Specializing the debugger to only work against a single tab at a time may not be possible (based upon how Firefox works, internally) but if it is that will be an immediate benefit. Of course, any performance improvements to the debugger will always be helpful.

Finally, the overhead of network monitoring (if there really is that much – we haven’t run performance analysis her yet) needs to be diminished in any way possible.

All of these things are points that the new Mozilla Firebug team is trying to tackle for the upcoming Firebug 1.3 release.

Who enabled me?

Taking in to consideration the above performance points (namely the fact that enabling the Console, Script, or Net panels have the potential to incur a global overhead on all browser tabs) a feature was added to help you minimize your use of the panels in errant tabs.

If you position your mouse over the Firebug icon, in the Firefox tray, a tooltip will pop up telling you two things: The version of Firebug that you’re using and which tabs have some Firebug panels enabled in them.

It should be noted that the Firebug will be a gray color if no tabs currently have a Firebug panel enabled at all.

Using the above tooltip you can now go in and selectively disable any panel usage that you are no longer utilizing.

Suspend/Resume Firebug.

Of course, when using the above tooltip (or seeing that the Firebug icon is lit up), you’ll just want to suspend all use of Firebug panels straight out without having to poke-around each individual tab.

A new Suspend/Resume menu option has been added that will suspend/resume all active panels. This is a one-click way to keep Firebug in check.

So what’s next for Firebug? I discussed some of the performance auditing that we were doing recently and that will be continuing.

Specifically, however, we plan on releasing some minor updates to Firebug 1.2 to quell bugs and improve performance (there will likely be a 1.2.1 release coming soon).

As I mentioned before, Firebug 1.3 is going to be all about performance, quality, and testing. Firebug is the de facto tool for web developers and we need to make sure that its quality does not wane and that we tackle performance head-on (with the eventual goal of having a seamless web development experience).