Archive for the 'Firebug Internals' Category

Web Debug Protocol group

Wednesday, July 15th, 2009

This post is aimed at debugger developers only: We have started an effort to create a standard remote web-debug protocol on the group WebDebugProtocol. The group is new-user moderated, so your first post will be delayed.

If you are not a debugger-developer but you meet one in a bar, please point them over to the group.


Adds User-Agent Stylesheet Editing to Firefox

Tuesday, July 7th, 2009

If anyone is interested in a small but high impact project involving Firefox C++ code for Firebug, take a look at [Bug 503007] Provide Javascript Access to User Agent Style Sheets. It involves extending an existing interface, so most of the work is in understanding how to create a patch consistent with the Mozilla coding requirements and in creating the matching test cases to pass review.

The feature would allow Firebug and Chromebug to support User Agent Style sheets properly.


Internals: FirebugChrome

Saturday, April 11th, 2009

I’m working to create a functional test for Firebug’s Open-In-New-Window feature and then to get the feature to work again. In the process I think I’ve finally decoded how this feature works.

Here is the critical bit: Every Firebug window has a different copy of FirebugChrome, but they all share the same copy of the Firebug and FBL objects.

If you’ve looked through the Firebug source you should be familiar with the modules (controllers) and panels (views). You will also know the ubiquitous Firebug global object that holds everything together, the ‘context’ for each web page, and the utility code like lib.js and domplate.js.

You will also have encountered FirebugChrome, but (if you are like me) its role seems a bit puzzling. It seems to be most–but curiously not all–of global UI related code. Now that I am deep into the open in new window feature, I can understand: it holds just the code to run the Firebug window UI, whether that UI is in the browser or in a separate window.

When you open Firebug in a new window you already have one copy of FirebugChrome in the Firefox window. This object manages the various bit of the Firebug ‘chrome‘: the XUL overlays (browserOverlay.js and firebugOverlay.js), the XBL (bindings.xml), and all of the CSS. In the scope of the new Firebug window, a newly created FirebugChrome manages the chrome in the window. This window is of course not Firefox (browser.xul) but simple window defined in firebug.xul.

That is not so surprising, but the next step is: immediately the newly created FirebugChrome sets the global Firebug and FBL objects to point back into the original Firefox window. So all of the modules, panels, reps, and the context management code in Firebug are shared across the windows, but the FirebugChrome is unique to each window. This is how Firebug can ‘detach’ and ‘reattach’ to the browser: the metadata is shared and never has to moved or synchronized between windows. (This is also why you almost never see window global object used in Firebug).

One function shows the special role of FirebugChrome more than any other: setFirebugContext(context). This function (renamed in v1.4 from showContext()) simply sets the global FirebugContext object to the argument context. Beneath the simplicity lies the clues to how Open-In-New-Window works. Consider the call from a Firebug method:;

Here browser is essentially Firefox tab. Hanging off the tab is a reference, chrome, to the FirebugChrome object managing the Firebug window for the tab. If Firebug is open in Firefox, then chrome points to FirebugChrome in Firefox. But if Firebug is open in a new window, chrome points to a different FirebugChrome, the one managing the firebug.xul window. So when we execute setFirebugContext() we cross from the global object Firebug into the window-specific object FirebugChrome and then we set a global object, FirebugContext to one of the context objects. That’s how we get two different values for FirebugContext, one in Firefox and one the new Firebug window. Got it?


Firebug Internals: Firebug’s private namespaces.

Monday, February 16th, 2009

Wladimir Palant’s great post about using namespaces in XUL overlays gives me another chance to explain one aspect of Firebug source that throws some folks off at first.  All the Firebug source files have the following construct:

FBL.ns(function() { with (FBL) {const Cc = Components.classes;
const Ci = Components.interfaces;
...more constants...

Firebug.Debugger = ....

...more code...


What’s that stuff about? Well this code creates a giant private namespace for Firebug. The outer function FBL.ns() calls the anonymous function defined within it like this:


So the body of the file is run with ‘this‘ set to an empty and anonymous object, rather than the default, ‘window‘.  So, presto, no name conflicts like the one’s Wladmir points out.  We then can expose just the objects we want, mostly by attaching them to 'Firebug‘, an object defined in firebug.js as a property of the window ‘top‘.

The other thing going on is the  ‘with (FBL) {}‘, which injects all of lib.js into the namespace. Thus all of these utility functions can be called directly, just as if they were built in to the environment.

This namespace wrapper is a bit strange at first, but you quickly forget about it and concentrate on the code in the middle, secure in the knowledge that you are immune from the naming conflicts.


Firebug Internals: tests online

Wednesday, January 14th, 2009

We finally managed to the Firebug’s test cases on-line.  These directories mirror  the fbug svn project tests directory.

Often users will have a sequence of Firebug operations that fails for them, but we need a page to try the sequence.  Now when a user has a bug report without a test case we can offer some example files for their test procedure.

The test cases fall into three categories:

  1. tests/issues: user reports converted to demo the bug; numbers match the issue list.
  2. tests/unit: our ever growing fireunit test suite.
  3. tests/<panel name>: demo cases for features

Thanks to robcee, reed and the Mozilla team for this support.


Firebug Internals: ShowContext gets called twice?

Tuesday, November 25th, 2008

I’m going to try to mention tidbits of info about Firebug implementation in this blog, under the category Firebug Internals.  They won’t make any sense unless you are looking at the Firebug source.

I was talking with Mike Collins about Firebug events and he was puzzled about the “ShowContext” event. Firebug modules (common logic units) get this event twice for every page load. Why?

ShowContext is intended to signal that the Firebug UI is now going to be shown to the user. When should that be? Well as soon as possible is mostly the answer. Certainly you want the Firebug UI to come up before the onLoad event for the page in case the developer needs to debug things that happen before that. Thus one ShowContext is sent as early as possible after initContext. But Firebug also wants to update the UI later and it uses ShowContext again at that point.

Firebug extensions then need to use ShowContext to refresh their view based on any data that may have changed. Roughly speaking a module will see initContext, showContext, loadedContext, and showContext as the page loads.  We’re hoping to make this more certain when we get support for document load started events.