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).
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:
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.
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.
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).