Firebug 1.6 Initialization Refactoring

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Goals: add a link to Firebug 1.7 refactoring page)
m (Changed link description for architecture refactoring)
 
(5 intermediate revisions not shown)
Line 1: Line 1:
-
= Goals =
+
== Goals ==
* Enable Firebug to initialize modules independently from panels.
* Enable Firebug to initialize modules independently from panels.
* Load/run Firebug modules in Fennec.
* Load/run Firebug modules in Fennec.
-
* Investigate other issues / pain-points that will need to be addressed for [[Firebug_1.7:_Architecture_Refactoring]]
+
* Investigate other issues / pain-points that will need to be addressed for [[Firebug 1.7: Architecture Refactoring | Architecture Refactoring]]
* Connect Firebug modules in Fennec/Firefox to Firebug panels in another Firefox process via Crossfire.
* Connect Firebug modules in Fennec/Firefox to Firebug panels in another Firefox process via Crossfire.
 +
* See also [[Firebug4Fennec]]
-
= Non-Goals =
+
== Non-Goals ==
-
== Activation ==
+
=== 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.
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 =
+
== 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).
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).
Line 28: Line 29:
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.
-
= Top-level objects: Firebug (firebug.js) vs FirebugChrome (chrome.js) =
+
== 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.
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.
+
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).
-
= Module Sandboxes =
+
== FirebugLoader ==
 +
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
-
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.
+
We may find that FirebugLoader is firebug.js
-
= Consequences =
+
== 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.
+
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.
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 =
+
== 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).
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).

Latest revision as of 11:43, 21 May 2010

Contents

[edit] 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 Architecture Refactoring
  • Connect Firebug modules in Fennec/Firefox to Firebug panels in another Firefox process via Crossfire.
  • See also Firebug4Fennec

[edit] Non-Goals

[edit] 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.

[edit] 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.

[edit] 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).

[edit] FirebugLoader

The new FirebugLoader will be

  1. Called on-demand, the first time the user opens firebug in a browser session,
  2. Called by some small UI integration code (eg status bar icon logic),
  3. live in application space, a module or component
  4. Use a small configuration to drive loading (different for Firefox, Fennec, Front end)
  5. Create the global Firebug application object,
  6. Load modules code in to sandbox scopes,
  7. Support dynamic load and unload,
  8. Eventually support CommonJS requires() loader syntax

We may find that FirebugLoader is firebug.js

[edit] 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 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.

[edit] 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