Firebug 1.6 Initialization Refactoring
- Enable Firebug to initialize modules independently from panels.
- Load/run Firebug modules in Fennec.
- Investigate other issues / pain-points that will need to be addressed for Firebug_1.7:_Architecture_Refactoring
- Connect Firebug modules in Fennec/Firefox to Firebug panels in another Firefox process via Crossfire.
- See also Firebug4Fennec
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
- FBL.initialize() - loads namespaces
- 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.
Currently some of the module and UI initialization is done in chrome.js, and some in firebug.js. Some of the UI initialization probably needs to happen from firebug.js, however a lot of the initialization/shutdown UI code is intertwined with the module initialization. A good place to start is to move the UI initialization calls into separate functions (such as 'initializeUI()' which already exist).
The new FirebugLoader will be
- Called on-demand, the first time the user opens firebug in a browser session,
- Called by some small UI integration code (eg status bar icon logic),
- live in application space, a module or component
- Use a small configuration to drive loading (different for Firefox, Fennec, Front end)
- Create the global Firebug application object,
- Load modules code in to sandbox scopes,
- Support dynamic load and unload,
- Eventually support CommonJS requires() loader syntax
We may find that FirebugLoader is firebug.js
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 different window, component or sandbox, 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).