Non-Goals

Activation

We don't want to make any changes to how/when/why Firebug is activated for a particular page. This is complicated enough in and of itself. Therefore specifically avoid changing any code or functionality at this point that would affect or alter the activation code.

Changes to Firebug initialization process

Currently Firebug's architecture separates the UI (panels) from the supporting code which interfaces with Firefox and the web page (modules). However, Firebug's initialization sequence is triggered when the XUL panelBar is loaded (in order to be loaded ahead of any onload event).

So the current sequence looks like:

panelBar constructor - called when panelBar XUL is overlaid

FirebugChrome.panelBarReady()

FirebugChrome.initialize()

FBL.initialize() - loads namespaces

Firebug.initialize()

dispatch "initialize" to modules

In order to allow the modules to run in a separate process from the Firebug UI, we will need to be able to do the last 3 independently of the first three. That is, make a call to FBL.initialize to load all the namespaces, call Firebug.initialize() (or some other function that does the necessary initialization) and then dispatch the "initialize" message to all registered modules.

Ideally this initialization would be exposed through a simple API which could be called, e.g. when Crossfire creates a successful connection.

Top-level objects: Firebug (firebug.js) vs FirebugChrome (chrome.js)

Modules will need access to (at least) the top-level Firebug object. Panels and other UI will need access to both the top-level Firebug and FirebugChrome ( or Firebug.chrome) objects.

The most straight-forward approach is probably to move any UI or window specific code in from firebug.js into chrome.js.

Module Sandboxes

If we can successfully isolate the code for individual modules this paves the way for loading modules into individual sandboxed enviroments (which contain only the top-level Firebug object). This would enable dynamic loading/unloading for Firebug modules.

Consequences

Currently since FBL.initialize is being called from a XUL window context all the module namespaces are created in the window's scope. If instead this is called from a component, some things might break. Since the modules are mostly isolated in their namespaces, this should not be a huge problem, although some code that relies on properties like 'window' or 'top' might have to be fixed or moved.

We also don't know how and/or don't have a reliable way to tell how many Firebug extensions may depend on code in their modules being able to access FirebugChrome, for example.

Contexts and Crossfire

Panels and Modules communicate in Firebug via the context objects. Once we are able to load the modules in a separate environment from the panels we will need a mechanism to communicate this context information, either through a local API (maybe 'dispatch' is enough?) or possibly by extending Crossfire (for remote/Fennec).