As the web continues its trend from static pages to rich interactive content and applications, the role of a software developer only grows.   As this movement continues, our need for becoming fluent with web-based debuggers is undoubtedly of the utmost importance.

For those of you unfortunate enough to work in the world of Internet Explorer, MS Script Editor or MS Visual Studio is probably your only tool of (mis)choice. To me it has been more like a blunt instrument than a precision tool.   It offers basic functionality but trying to use it beyond that it causes constant frustrations. Basic conditional breakpoints often crash Visual Studio, and more advanced conditional breakpoints refuse to be set. Stepping through code too fast occasionally freezes up Visual Studio 2005 through 2008 to the point only a task kill can shut it down.  In short, it has been a constant struggle for me to work with these MS based tools.

Which brings us to Firebug, the best JavaScript debugger that I know of. I’ve found Firebug to be a much a more powerful debugger than MS Visual Studio for a long time.  I could write dozens of blog entries about this ever-evolving debugger of choice (and I plan to), but this article is meant to describe how to patch a randomly occurring bug in the current 1.5 release (at time of writing), using a fix recently provided in the upcoming 1.6 release.

The Bug

I have used firebug for a long time, but I never came across this bug until I started work at NexJ. Their software applications offer amazingly advanced functionality, which of course requires more advanced coding. And with this advanced coding comes:

1. More JavaScript Files
2. Larger JavaScript Files

With these two ingredients, the debugger script view will randomly:

1. Cut off the display of certain JavaScript  files at random line numbers.
2. Make certain breakpoints no longer fire after random line numbers
3. Make breakpoints repeat themselves on refresh, while referring to “undefined” functions.

I’ve kept in contact with some of the developers on the IRC and have been tracking the bug. Thankfully it appears a fix was committed to the upcoming 1.6 branch.  I’ve modified the patch slightly to apply to the 1.5 branch, and it has solved all of the above beautifully.

The Fix

The patch is very simple.

Step 1) Open up firebugs tabPanel.js file.

C:\Documents and Settings\YOUR.PROFILE.NAME\ApplicationData\Mozilla\Firefox\
      Profiles\RANDOMSTUFF.default\extensions\firebug@software.joehewitt.com\
      content\firebug\tabCache.js

C:\Users\PROFILE.NAME\AppData\Roaming\Mozilla\Firefox\Profiles\
      RANDOMSTUFF.default\extensions\firebug@software.joehewitt.com\
      content\firebug\tabCache.js

/home/LOGIN_NAME/.mozilla/firefox/RANDOMSTUFF.default/extensions/
      firebug@software.joehewitt.com/content/firebug/tabCache.js

Step 2) Find the line similar to:

sink.init(true, true, 0, 0, null);

sink.init(false, false, 0x20000, 0x4000, null);

Step 3) Directly after this line add:

newListener.wrappedJSObject.inputStream = sink.inputStream;

Step 4) Save the file, kill all instances of Firefox, and restart Firefox. All fixed!

The original patch can be found here,  but is based on the 1.6 branch which is likely different than what you are running at the time of this post.

Explanation:

The problem was that the reference to the input stream was lost and was randomly collected by the JS garbage collector. This is why the bug is random and more prevalent on some machines (probably with lower memory conditions at the time), and why it was more likely to occur with more and larger files (allowing greater opportunity for the garbage collector to get in the way).

The good news is this problem will no longer require a manual patch once the 1.6 branch becomes an official release.

Let me know how this works for all of you, and happy debugging!