Subscribe to RSS Feed

Firebug 2 (released today!) uses number of internal architectural concepts that help to implement new features as well as effectively maintain the code base.

Using transparent architecture and well known design patterns has always been one of the key strategies of the (relatively small) Firebug team that allows us maintain rather large set of features in Firebug.

This post describes the way how Firebug deals with JavaScript object representation and the concept ensuring that an object is always rendered the same way across entire Firebug UI.

  • Firebug 2.0 is compatible with Firefox 30 - 32


See also list of new features in Firebug 2

Firebug Internals I.

Unified Object Rendering

Firebug (as a web developer tool) is primarily dealing with JS objects coming from the currently debugged page. All these objects are displayed to the user allowing further exploration and inspection. Important aspect of the rendering logic is that an object is always rendered using the same scheme (a template) across Firebug UI. It doesn't matter if the object is displayed in the Console panel, DOM panel or inside the Watch panel when Firebug is halted at a breakpoint. It always look the same and also offers the same set of actions (through the context menu).

Let's see an example. Following three images show how <body> element is displayed in different Firebug panels.

Here is <body> logged in the Console panel.

This screenshot displays <body> in the DOM panel.

And the last screenshot shows how it looks like in the Watch side panel.

The element is always rendered using the same template and also the context menu associated with the object offers the same basic actions (plus those related to the current context).


The architecture behind unified rendering is relatively simple. The logic is based on a repository of templates where every template is associated with JS object type (number, string, etc.). When a panel needs to render an object it gets its type and asks the repository for a template that is associated with it. The template is consequently used to generate HTML markup.

Firebug uses Domplate engine fore templates, but any other templating system could be used instead.

  • An object (JS object coming from debugged page content) is logged into the Console panel.
  • The panel asks the repository to render the object.
  • Repository gets the right registered template for the object (done usually according to object's type).
  • Finally, the template renders itself using the original object as data.


Let's yet see a few code examples that show how (simplified) implementation looks like from JavaScript perspective.

Here is how getTemplate can implemented (note that Firebug implementation is a bit different):

getTemplate: function(object)
    // Iterate registered templates and return the
    // one that supports given object
    for (var i=0; i<templates.length; i++) {
        var template = templates[i];
        if (template.supportsObject(object)
            return template;
    return defaultTemplate;

An interface of a template object looks like as follows (again simplified).

var Template =
    className: "",

    supportsObject: function(object) { return false; },
    getContextMenuItems: function(object) { return []; },
    getTooltip: function(object) { return null; },
    highlightObject: function(object, context) {},
    inspectObject: function(object, context) { },

  • className Every template should have a classname so CSS styles can be associated.
  • supportsObject Used to pick the right template for an object
  • getContextMenuItems Used to get commands that are should be displayed in the context menu.
  • getTooltip Provides a text that is displayed in a tooltip.
  • highlightdObject Can be used to highlight the object within the page if mouse hovers over the object.
  • inspectObject Can be used for further inspection of the object (e.g. selecting the right target panel when the user clicks on the object).

See real repository of templates (a template in Firebug is called rep) on github.

Extension Points

The entire concept is also nicely extensible. This is great especially for extension (i.e. Mozilla add-ons) authors that can plug in into the logic and customize it.

  • Extensions can provide and register new templates that are rendering specific object types (coming e.g. from JS libraries like jQuery or EmberJS) and define how objects are rendered across entire UI.
  • Extensions can also provide a set of actions that can be performed on existing of custom object types.
  • Extensions can specify new CSS for existing templates and create custom themes.

Rss Commenti

No comments yet

No comments yet.

Sorry, the comment form is closed at this time.