Archive for March, 2010

Recommend Firebug 1.5

Monday, March 22nd, 2010

Alix Franquet from Mozilla just announced a survey on Firefox 3.6 and Firebug 1.5. Only one page, ten questions, but one of the questions allows you to say if you would recommend Firebug 1.5. I hope you will!

Please take the survey now.


Firediff 1.0

Monday, March 22nd, 2010

In case you missed it, Kevin Decker has released Firediff 1.0, a change tracker for Firebug:

Lots of new features:

  • Revert Changes
  • Save Snapshot
  • Save Diff
  • Document Formatters
  • Search
  • Activation Data Handling Improvements
  • Style attribute change handling

More details on his Web site.


Please post comments on the newsgroup.

What’s this other crank for?

Sunday, March 21st, 2010

During the demo of Charle’s Babbage’s Difference Engine #2 at the Computer History Museum, a docent turns a large hand crank to compute values of a 7th order polynomial by divided differences and print the results. After the demo I noticed another crank on the opposite end of the machine, awkwardly positioned near the ground:

Debug crank for Charle's Babbage's Difference Engine #2.

jjb: “What’s this other crank for?”

docent: “We use that to debug the machine.”

jjb: “(D’oh!)”.

A clutch on the drive line connecting the operator crank to the printer allows the printer and calculator to be decoupled.  The secondary crank can then operate the printer independent of the calculator. Classic divide and conquer debugging.


For followup comments, please use the newgroup.

Firebug Dreams

Thursday, March 18th, 2010

Some ideas for Firebug beyond Firebug 1.6 and 1.7:

Javascript edit and go: Currently you can edit the DOM values, CSS rules, and HTML elements and attributes. But you can’t edit the Javascript. So JS developers miss out on the quick-let’s-just-see model so popular and powerful for other users of Firebug.

Automatic or Query-based Logging: Now we have to edit our Javascript to add console.log() statements. Some times we just want to know: what code runs when I do this? A simple way to summarize the execution path would be automatically inserted console.log() calls on every function call or every call matching a pattern and so on.

CSS by Example: If you know CSS, Firebug let’s you into tweek a page to perfection. But what about the rest of us? Every time I mess with CSS I have to spend most of the time reading docs or looking up examples. I’d like a “for example” mode that shows me just a bunch of different thing CSS can do to an element.

CSS Connectors: Actually I don’t know how to name this or exactly what I want. I do know that want fluid layout but I don’t want to read forty different ways to do three column layout again. Maybe we can extend the Firebug inspector to show the box hierarchy and/or the boxes that the selected box is directly related to.

Live Object Sites: By a large margin the most requested feature for Firebug is Issue 179, Create a unified patch from CSS changes. As you can see in that issue there are two Firebug extensions that solve this for some cases. Our work on 1.6 should make those extensions easier to install and update. But this is just the start: we want every kind of edit to be synchronized. Maybe should also explore more aggressive approaches like Dan Ingalls’ Lively Kernel.

Memory Analysis: As Web applications grow and grow we are increasingly running into memory limitations. Analyzing memory usage is hard; I think we need several different approaches. We are looking at trying to use a Memory analyzer created by Dion Almer and Atul Varma and their colleagues. It gives you the number and sizes of objects. We’ve also discussed a “high memory” analyzer,  part of a JS function profiler that would just tell you which functions bumped up the high-water mark, a very fast way to pinpoint a serious problem. Another critical tool would find back links for a given live object: why isn’t this one being garbage collected?

Widget-set Debugging: Many Web pages these days are built on toolkits like Dojo, ExtJS, jQuery, or Scriptaculous. Users at the toolkit level think in terms of widgets and events of the toolkit, so debugging at the HTML and DOM event level is tedious and confusing. Firebug should have direct support for toolkit debugging.

Code Coverage: Lots of folks use test-driven development or at least have some test suite for their code. We need some easy to use ways of finding out what parts of the code are not being touched by our test suites. We also need to know what  HTML and CSS does not actually contribute to the page even if it is shipped to users.

Integrated Debugger Environment: Firebug should support multiple simultaneous views of more than one panel and have better integration support with editors and Web servers.

FireCrystal and WhyLine: Stephen Oney in Prof. Brad Myers’ group at CMU has a very cool prototype for a graphical tracing tool called FireCrystal; it animates a time line with snap shots of the Web page so you can find out when a particular UI change happened or study the graphical update in slo-mo. A former student of Prof. Myers, Andy Ko, now a Professor at U Wash., created a Java debugger for graphical applications that supports query-style debugging. I’d love to explore the potential for these ideas in Firebug.

Finally, I am collaborating with Salman Mirghasemi and Prof. Claude Petitpierre from Ecole Polytechnique Fédérale de Lausanne, on Salman’s new approach to conditional breakpoints (well that hardly does the justice to the idea) and we hope to bring some of these ideas into Firebug.

The Firebug issues list has a lot of other great ideas for enhancements.  If you have a cool idea or suggestion not on one of these lists, please let us know in the newsgroup.


Firebug 1.6a8

Wednesday, March 17th, 2010 has Firebug 1.6a8; it includes 6 bug fixes.

Steve Roussey and Jan Odvarko struggled for a long time and they finally solved Issue 2788: Script panel files get truncated.  The symptom was long script files being truncated.  First it was a while to get a test case; then quickly we determined that the file lines were just not in memory. Eventually the bug: we created an object sink and used it in an platform api:

                var sink = CCIN(";1", "nsIPipe");
                sink.init(false, false, 0x20000, 0x4000, null);
                var originalListener = request.setNewListener(tee);
                newListener.wrappedJSObject.sink = sink;
                if (tee.initWithObserver)
                    tee.initWithObserver(originalListener, sink.outputStream, newListener);

Seems ok, but there is a silent race: the sink.inputStream will be read from up until the sink object is garbage collected.  No way to tell from this code however.  Boris Zbarsky found it with a C++ debugger. I wonder what kind of Firebug feature would have helped us with this probelm?

Also in this release is a small change to the command line implementation to reduce the stuff we inject into the Web page. This marks the start of more aggressive changes for 1.6, now that we are moving past 1.5.

This release passes all tests in FF 3.6 (more all the time thanks to Jan “Honza” Odvarko!).  We also set the maxVersion back to FF 3.7 now that tasoss offered to test Firebug 1.6 on Firefox 3.7 nightly builds.  Not all tests pass on 3.7 but its not too bad for alpha on alpha software.


Please followup on the newsgroup.

Firebug Reflections

Wednesday, March 17th, 2010

The third anniversary of my first Firebug contribution is coming up, so it’s time for a little reflection and dreaming.

We’ve come along way since Joe Hewitt unleashed Firebug 1.0.  Arriving at the start of the Web 2.0 revolution, Firebug helped shift people from thinking Web 2.0 was a fad to realizing Web apps can be real. Firebug had to grow up in a hurry while we still did not understand the code well and certainly didn’t understand Firefox.

Firebug 1.1 wasn’t really meant to be, used by a few dedicated and helpful folks. So Firebug 1.2 was our first real release beyond Joe’s original source. Behind the scenes we had lots of extra work to close a security hole in Firebug.  At the time we could not tell anyone: too many users were exposed.

Firebug 1.3 was originally planned as a stop-gap release, but thankfully it was pretty solid, because Firebug 1.4 started off as a bizarre disaster: a lot of unpopular UI changes masked a serious UI bug that took weeks to discover. Firebug 1.5 went a lot smoother, partly by luck but mostly because we finally have a solid test suite and working debugger for our debugger.  Firebug 1.5 just entered the history books; we’ll know in a few months how we did.

Some people use Firebug as an inspection and tweeking tool; some use its console or net panel; some use just the Javascript debugger. But for most users the real power of this first ever Web debugger is synergy.  No combination of independent inspectors, consoles, net-traffic analyzers, and debuggers provides the same level of support for developers. Pivoting between panels and using one view to trigger action in another is how Firebug Ninjas work.

The world of Web development changed in three years. Other browsers gave up on small independent tools , they now have debuggers that look and act an awful lot like Firebug; there are even another browser now and it comes with a Firebug-like debugger built-in. While I am hardly unbiased, I think Firebug remains the best of the bunch, both in terms of overall design and in terms of a rich and appropriate feature set. For that we have a lot of  talented and dedicated contributors to thank!

But what about the next three years? I’ll do a little dreaming in my next post.


Follow up on the newsgroup please.

Firebug 1.5.3

Friday, March 12th, 2010 has Firebug 1.5.3. This release fixes four issues we found (or created 😉 ) in Firebug 1.5.2.

In particular this release works around a large memory leak.  Special thanks to ben.amada for putting together the test case that helped us track this down.

We will update Firebug users  later today.


Please followup in the newsgroup.

Chromebug 1.6a7 and Firebug 1.6a7

Tuesday, March 2nd, 2010 has Chromebug 1.6a7 and Firebug 1.6a7.

Yes, I know we just had Firebug 1.6a6. But Chromebug had one problem left to fix: the context did not restore correctly after restarting. After working all afternoon I tracked it down to a line in Firebug.

Plus the Firebug command line in 1.6a6 was broken if you used NoScript. What? NoScript and Firebug? Hey it happens.

This version of Chromebug has a big clean up in the code. Some highlights:

  • Sandbox context have better names,
  • Sandbox contexts use evalInSandBox for their command line,
  • New panel XPCOM for non-window contexts (eg BackstagePass)
  • New panel Overlays for window contexts (eg browser.xul).

I’ll do a post with screen shots on these soon.


Follow up in the newsgroup please.

Firebug 1.6a6

Tuesday, March 2nd, 2010 has Firebug 1.6a6. It has fixes for 13 bugs. Notable changes:

  • Support for private browsing mode,
  • Open-in-new-window Firebug now looks like in-browser firebug,
  • max version 3.6 since we are not testing on 3.7,
  • work around for memory leaks discovered in Firebug 1.5.2

The memory leak fix, console.dir() bug fix and perhaps one more will be merged in to 1.5 for 1.5.3 next week.


Please followup in the newsgroup.