Here’s a not-terribly hypothetical situation you might imagine. You’re a web-developer working for a small company. You’ve got a website. You want to do some debugging on your front-end scripts. Naturally, since you have Firebug installed, the first thing you do is drop a few of these around your code:

console.log("I am here!");

Simple, effective, printf-style debugging. Then you decide you want to show your manager what you’ve done on her own computer. You point her to the address and she loads it up and says, “this is broken. I don’t have Firebug installed so I’m getting exceptions calling console.log().”

Pwnd! You throw in a check that might look like this:

if (window.console) {
  // set a variable, do some stuff, maybe write
  // your own log() wrapper...

Problem solved!

Maybe then, you start getting fancy and add a timer to your new logging function.

function myLogFunction(method, message) {
    console.time(method.toString());
    var result = method();
    console.timeEnd(method.toString());
    console.log(message, result);
}

Neat-O! Except, console.time() isn’t a function in some browsers and now won’t work properly.

One possibility is to check explicitly for Firebug by expanding your first window.console check like this:

if (window.console && window.console.firebug) {

That’s become a fairly standard pattern, though I believe it’ll exclude Chrome, Safari and Opera from your debugging efforts.

A better way is to test for each function you want to use:

if ("console" in window && "time" in window.console)
    // define your method

This has the benefit of not coding for one particular type of debugging tool, will allow for graceful fallback in the event that your feature is not defined and allow you to tailor your debugging around different feature sets. This is the way libraries like jQuery check for browser capabilities and you should too. You want your website to work everywhere, don’t you?

An even better way around this would be to not ship your debugging code in a production web-site, but you may have good reasons to ignore this advice.

• Enhanced Inspector
• More accurate Net panel timings
• Break on HTML mutation
• MathML and SVG namespace support
• Break on XHR
• Improved HTML editing
• Persist buttons on Console and Net panel
• Separate Computed CSS and Style subpanels
• Many many bugfixes and stability improvements

This is a huge release and these are just some of the highlights you’ll see in this new version. Please feel free to read the release notes and John Barton’s blog post for more details.

As always, if you encounter any problems, don’t be shy about filing a bug! We’ll be following up with quick point-releases if and when you find issues.

Special shout-outs and thanks to Mike Ratcliffe for the Inspector improvements, Steven Roussey for HTML editor improvements, SVG and MathML namespace patches, Honza for being awesome and John Barton for his tireless contributions.

If you’re new to Firebug, you might want to check out my introduction to Firebug screencast.

(This post has been translated into Belarusian by Marcis G. Thanks!)

Right click and download in .ogg. or .mpeg4 to see the video in full-size.

First, a little terminology. Feel free to skip this paragraph if you consider yourself a master of Javascript internals or compiler run-time optimization makes your skin crawl. Tracing is the mechanism Firefox’ Javascript engine (aka, “SpiderMonkey”) uses to improve code execution performance. It provides a major speedup for code running in Firefox 3.5 and up, often an order of magnitude for certain types of operations. It is the basis of the JIT or Just-in-Time compiler. Without tracing, the JS engine can’t optimize code as well, leading to significantly slower execution.

I need to be clear here: If you have Firebug installed you are probably not getting fast Javascript. Firebug doesn’t have to be active on your current page. If you have the grey icon on your status bar, you have probably disabled the JIT. This is true if you have ever enabled the Console and consequently the Script panels and left them on. This is likely true for most recent versions of Firebug. The quick fix is to disable the Script and Console panels via the mini menu on their respective tabs.

Boris Zbarsky has been doing a lot of poking around in the belly of the JS debugger lately. Working in conjunction with John Barton, they have concocted fixes for the soon-to-be-released Firebug 1.5 and Firefox 3.6. We’re working to get testable versions out as quickly as possible, but I can say that I’ve tested development builds using the pages mentioned in the bug and can verify that these fix the problem. As a side-benefit, I got to watch Boris dissect the problem through gdb in an Xterm (yes, an Xterm) and Emacs and it was pretty impressive and fun, to boot.

When installing Firebug one of the first things most people do is enable the Console. It’s such a useful debugging tool. I myself have been using Firebug for over a year without JITted code. I probably never noticed the slowdown simply because I’m so used to running my browser this way and have pretty fast machines. After disabling the Console and Script panels there are a few pages that just load much much quicker. It’s kind of shocking.

Since the patch has landed on Firefox 3.6, I’m expecting either a beta or release candidate of that to come out shortly. I’m also hoping for another Firebug beta (or release candidate) later this week. In the meantime, if you’re not using them, I recommend disabling the Console and Script panels and find out what you’ve been missing and turn them on only as-needed. This will likely be the work-around for Firefox 3.5 users unless we decide to push this back to that branch but I have my doubts that this is something we would do.

Improved Net Panel accuracy

One of the problems with Firebug’s Net panel in the past has been inaccurate timings. Because Firebug is entirely written in JavaScript some network and UI activity could block Firebug during long operations and cause the timings displayed there to be less than accurate. This has finally been corrected with the landing of a new service called the http-activity-distributor. For more details on the implementation and use of the newly-improved Net panel, see Honza’s blog post on the topic.

New Break Functionality

In Firebug 1.4, we introduced the concept of “break-on-next” to the Script panel. This was a “pause” button sitting between the inspect icon and the Console tab. In 1.5, we’ve extended this concept to the Console, HTML and Net panels to allow more exciting types of breaks.

In the Console, we’ve replaced the mini-menu Break-on-Errors option with the pause button. The reasons for this possibly contentious change was it made for a more consistent use of menus and the break button. Now, to enable Break on Errors, select the Console panel and hit the pause button. You’ll see that familiar glow to indicate that it’s waiting for an error. Now whenever an error occurs on the page, you’ll be dropped into the script panel at the line where the error occurred.

The HTML panel’s break button is a little different. This is the Break-on-Mutation feature. When this is enabled, whenever a bit of JavaScript modifies an HTML element, you’ll be taken to the Script panel and the modifying code while be highlighted. Related to this, you should be able to see modified HTML occurring in real-time in the HTML panel with affected elements and attributes being highlighted as they change in the page.

Finally in the Net panel, the break button acts as a Break-on-XHR button. This is intended to help debug AJAX apps by allowing you to halt the debugger during an XmlHttpRequest send. As in the other break types, you’ll be transported to the script panel when an XHR object fires off its request and you’ll be given the option to copy the message.

John Barton and Honza have written a great interactive demo page describing these new features on getfirebug.com.

Mixed Development

• We made a few tweaks to the UI in this version. We replaced the “Off” label with a single “power” button (or window close button on Mac) as promised during the last release.

• Kevin Decker added the search panel originally intended for version 1.4 with some nice options

• Persist option on Console and Net Panel. Save your data!

• Improvements to the Inspector.

Still more to come. Between now and final release we plan on hunting down a few more bugs to make this even more stable. Feel free to download and give it a try.

As in the previous poll, I added a Junk column for responses that didn’t really make sense. “I <3 Firebug!” is great to hear (and Firebug <3s you too!) but it wasn’t really useful for the purposes of this poll. Augmenting this column, I created another category for responses lamenting Firebug stability or specific missing features. This was tied for first place with the most votes.

The Winners

Third place – Tie!

• Search feature
• Console. Surprised some people dislike the Console, but two of you did. One person mentioned a lot of exceptions coming from the browser showing up in the Console lowering the quality of information. These can often be cut down by unchecking the “Show Chrome Errors” and messages options in the Console’s mini-menu.

Second place – Tie!

These have the dubious distinction of having the same number of responses as the Junk column.

• CSS panel
• DOM panel
• Profiler

First Place

• Script panel — Responses varied from “I don’t know how to use breakpoints” to users who prefer using the Console to do printf-style interactive debugging. Other respondents claimed the script panel was just too buggy.

caveat: I believe there is probably more than one type of user of Firebug. Some of them may not be using Twitter and this poll might not have gotten to them. The types of users who replied and said that their favorite feature was the HTML Inspector and live-editing of CSS are probably the same group of people who don’t make heavy use of the Script debugger. If you’re a heavy debugger, please let us know in the comments.

Honorable Mentions

• HTML node editor – If you double click on a tag in the HTML view, you’ll see the node editor. Clicking the “Edit” button or using the Escape key will get you out of it.
• Event logging – right click on a node in the HTML viewer and select “Log Events”. Now every mousemove, click and keystroke in that node will be registered in the Console. How can you not love that?

There were no votes(!) for the Net panel, so everyone clearly loves it and thinks it’s awesome.

Take Aways

• we need to work harder on bugfixes and stability. Spending a lot of effort on stability and usability would probably go a long way towards making Firebug a better, more pleasurable to use piece of software.

• The CSS and DOM tabs aren’t loved. Adding better navigation to the DOM page, or reworking it entirely might be useful. Getting rid of it and the CSS tab entirely could be another option but not one we’d consider doing without some very strong feedback from the community.

• The Profiler ties in with the Script panel pretty closely. If you’re not doing heavy JS debugging, you might not need the profiler. It’s a pretty special-purpose tool to measure a page’s JavaScript performance.

• Search feature was a bit of a surprise, but we’re improving that for version 1.5 so hopefully it becomes easier to use.

As before, please leave us your comments if you think we’re missing something.

The break-down in exploding 3D pie chart format shows that 55% of users call the Inspector their hands-down favorite feature. In reality, this is probably closer to 73% if you combine the HTML tab which 18% reported as their favorite. When most people think “inspect” or “html” the next feature they describe is “being able to modify the CSS or see the layout of that node in the HTML panel”.

The next favorite feature is a tie between the Net panel and the Console. It’s possible that since I first collected the responses that the tie has been broken, but certainly not by much, and probably not within a suitable margin for error. The remaining 9% of responses were incomprehensible internet sounds. The cosmic background static of emerging consciousness.

How does this help? Well, it certainly tells us where we need to focus our efforts. We have seen a few errors with the Inspector over the past couple of years and think in version 1.5, we’re going to have most of them fixed. Annoying highlighter offsets and weird z-index issues should be a thing of the past thanks to work by contributor Mike Ratcliffe who came to us through the Firebug lite project.

I’m going to follow-up a bit later with the results of the “least favorite feature” question. They’re a bit harder to make sense of as the answers weren’t quite as obviously clear. Please let us know if this pie chart matches (or doesn’t) what you think is your favorite feature, too. This isn’t the end of the question — we’re just getting started.

Firediff Snapshot + Diff Generation – In Case of Stairs

It’s still Alpha software, but it’s definitely getting there.

We’re in a bit of a funny place with Firebug and Firefox 3.6. The Firebug 1.5 line is currently running better on Firefox 3.7 (trunk, mozilla-central) than it is on the 1.9.2 branch (Firefox 3.6, aka Namoroka). Fallout from a couple of bugs is causing some strange scrolling problems in Firebug and likely, a few other add-ons. Worse, we’re unable to edit anything in Firebug’s HTML and CSS editors.

That should change shortly. We’re waiting for a small patch in bug 511951 to land and correct these issues and make everything right again. I ran a build with this patch last night and confirmed that everything looks good. Our tests ran fully with no errors.

If you’re the adventurous type, you may feel like grabbing our latest version, Firebug 1.5a24 from getfirebug.com/releases and giving it a whirl. There are some changes, some improvements and more than a few bug fixes. See the evolving release notes for details.

Orange ftw. Blog post to follow. http://twitpic.com/gcizx

Well, here’s the blog post.

That little orange box is the first successful run of Firebug’s FBTest test automation tool through buildbot. It’s currently posting to the MozillaTest Tinderbox.

This is phase 1. We’re currently running Firebug’s 1.5 branch out of SVN against the latest linux build available in the Firefox 3.6 tinderbox builds directory. These are kicked off by SVN checkins to Firebug and FBTest. To give better coverage, and be somewhat more useful to Firefox devs, we’re going to run the latest built version of Firebug 1.5 against Firefox 3.6 branch and 3.7 trunk after a successful Tinderbox build. This will give us a known quantity (a Firebug that works in 3.5) testing against the different Firefox versions for incompatibilities. This should allow us to spot regressions as they happen in Firefox and report them much more quickly.

Once these are setup, we’ll create a separate Firebug tree, or if the sheriffs and drivers are amenable to it, drop a column on the appropriate Firefox tree on Tinderbox. I also want to experiment with different notification systems.