Firebug 1.6 Initialization Refactoring

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
Line 27: Line 27:
Ideally this initialization would be exposed through a simple API which could be called, e.g. when Crossfire creates a successful connection.
Ideally this initialization would be exposed through a simple API which could be called, e.g. when Crossfire creates a successful connection.
 +
 +
= 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.
 +
 +
= 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).

Revision as of 22:37, 13 April 2010

Contents

Goals

  • 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 refactoring.
  • Connect Firebug modules in Fennec/Firefox to Firebug panels in another Firefox process via Crossfire.

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.

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.

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).

Personal tools