Firebug 1.7: Architecture Refactoring

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Detailed Work Plan For JS Reimplementation)
 
(15 intermediate revisions not shown)
Line 1: Line 1:
-
 
-
 
== Problems to be Solved by Refactoring ==
== Problems to be Solved by Refactoring ==
Line 7: Line 5:
** Client side will have no access to Firefox data
** Client side will have no access to Firefox data
* Allow simpler and more robust extensions
* Allow simpler and more robust extensions
-
** Javascript oriented loading, no xpcom loader required
+
** Javascript oriented loading, no XPCOM loader required
** Isolation and concentration of extension code
** Isolation and concentration of extension code
* Clean up expedient code and clarify the implementation
* Clean up expedient code and clarify the implementation
-
** relation to platform window system,
+
** relation to platform window system
** relation of panels and modules
** relation of panels and modules
** prepare/exploit shift to jetpack
** prepare/exploit shift to jetpack
Line 23: Line 21:
==== Issue: file names vs folders ====
==== Issue: file names vs folders ====
-
I understand the natural appeal of module/debugger.js and panel/debugger.js vs debuggerModule.js and debuggerPanel.js. However in my experience one needs to wrote with one kind of module plus panel much more often than all of the panels or all of the modules. Creating a subdirectory for each feature, eg debugger/module.js make lots of small folders. Any scheme where the folder is used to disambiguate makes lots of tools hard to use because you end up with a lot of UI selections like "module.js" or "debugger.js" and you can't tell what it means. That is how I ended up with debuggerModule.js and debuggerPanel.js: unambiguous naming with the feature first so alphabetic sort groups by feature.
+
I understand the natural appeal of module/debugger.js and panel/debugger.js vs debuggerModule.js and debuggerPanel.js. However in my experience one needs to write with one kind of module plus panel much more often than all of the panels or all of the modules. Creating a subdirectory for each feature, eg debugger/module.js make lots of small folders. Any scheme where the folder is used to disambiguate makes lots of tools hard to use because you end up with a lot of UI selections like "module.js" or "debugger.js" and you can't tell what it means. That is how I ended up with debuggerModule.js and debuggerPanel.js: unambiguous naming with the feature first so alphabetic sort groups by feature.
=== Components replaced by SharedObjects ===
=== Components replaced by SharedObjects ===
Line 33: Line 31:
* [http://docs.google.com/present/view?hl=en&id=dcd8d5dk_0cs639jg8 ECMA Harmony Modules]
* [http://docs.google.com/present/view?hl=en&id=dcd8d5dk_0cs639jg8 ECMA Harmony Modules]
* [http://commonjs.org/specs/modules/1.0.html CommonJS Modules]
* [http://commonjs.org/specs/modules/1.0.html CommonJS Modules]
 +
* [http://getfirebug.com/wiki/index.php/Narwhal Narwhal implementation of CommonJS]
This would put us on the same path as jetpack proposals.
This would put us on the same path as jetpack proposals.
-
As far as I know the CommonJS, as well as Mozilla platform Components.utils.module, supports common code loading, but we want common object sharing. So there may be some additional work on API.  
+
As far as I know the CommonJS, as well as Mozilla platform Components.utils.module, supports common code loading, but we want common object sharing. So there may be some additional work on API.
=== Recode TabWatcher -> DOMWindowWatcher ===
=== Recode TabWatcher -> DOMWindowWatcher ===
Line 48: Line 47:
=== Sandboxed Extension Loading ===
=== Sandboxed Extension Loading ===
-
By re-applying the module loading technology we can create a jetpack-like environmental wrapper for Firebug extensions. The extensions would be slightly simpler because they would just be zip files. They would be slightly more robust because they would be evaled in a scope that only contains Firebug.
+
By re-applying the module loading technology we can create a jetpack-like environmental wrapper for Firebug extensions. The extensions would be slightly simpler because they would just be zip files. They would be slightly more robust, because they would be evaled in a scope that only contains Firebug.
 +
 
 +
=== Refactor debugger.js <-> firebug-service.js API ===
 +
 
 +
Ultimately we want debugger.js to split into a front-end and back-end, with the back-end implementing Crossfire's V8-like protocol. So a start is to shift work between debugger.js and firebug-service.js to be an V8-like API, and use firebug-service.js as an adapter between V8-like protocol and Mozilla jsd. (Note that JSDebugv2 aka js::dbg should have this kind of API).
 +
 
 +
* [[Crossfire]]
 +
* [http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/d8.js?spec=svn4437&r=4437 D8 source] (V8 command line tool)
 +
* [http://v8.googlecode.com/svn/trunk/include/v8-debug.h v8-debug.h] header file for V8 debugger API
 +
* [http://code.google.com/p/v8/wiki/DebuggerProtocol V8 debugger protocol]
-
== Dependent on Firefox Improvements ==
 
-
=== Memory Panel ===
+
=== Workplan items (not yet in order) ===
-
This is one of top features. This has be requested many times and would be certainly very helpful for web app developers.
+
-
[https://bugzilla.mozilla.org/show_bug.cgi?id=515946  Bug 515946] -  jsd: Add support for memory profiling.
+
# Define a new interface ''Firebug.Middle''
 +
#* Functions equivalent to the Crossfire protocol
 +
# Define new module mozilla-backend.js
 +
#* Implements ''Firebug.Middle'' using jsd
 +
# Define new module crossfire-client.js
 +
#* Implements ''Firebug.Middle'' using Crossfire
 +
# Define new Firefox extension Crossfire-Mozilla
 +
#* Implements Crossfire server, calls mozilla-backend.js
 +
# Define new Chrome extension Crossfire-Google
 +
#* Implements Crossfire server, calls google-backend.js
 +
# Reimplement debugger.js to calls into Firebug.Middle instead of fbs.
 +
#* At load time Firebug.Middle is implemented using either mozilla-backend.js or crossfire-client.js
 +
# Implement ''FBTest.Middle''
 +
#* js unit tests that call into Firebug.Middle
 +
#* FBTest configuration to test mozilla-backend.js and crossfire-client.js looping through server
-
=== TabWatcher refactoring ===
+
=== Detailed Work Plan For JS Reimplementation ===
-
Have a solid Firefox event that is always fired (at the right time) when a new document is loading (no matter if it’s a web page, xslt, about:blank, etc.) and used to initialize page context for Firebug (i.e. call initContext). This is also one of the top things (for a long time).
+
-
[https://bugzilla.mozilla.org/show_bug.cgi?id=342715  Bug 342715] -  Need an API to allow extensions to hook "document load started" events
+
Please ask jjb about any code in debugger.js or firebug-service.js that involves 'jsd' or 'fbs'. This code is all going away and we don't want to invest your time in understanding it more than needed.
-
+
-
This should also help to significantly simplify the TabWatcher, which is one of the basic (and most hacky) drivers in Firebug (controls life cycle of the UI).
+
-
=== Add Support for Compilation Units to jsd/firebug-service ===
+
# Milestone '''BTI''': Interface, Unit Tests, firebug-service encapsulation
-
[https://bugzilla.mozilla.org/show_bug.cgi?id=449464 Bug 449464] -  Implement jsdICompilationUnit to extend jsd to include information on the compilation unit structure
+
## Preliminary: move mozilla-specific code from debugger.js to fbs, split out script.js (front end).
 +
## Define (initial) BrowserToolsInterface (BTI)
 +
## Create unit tests for BTI
 +
## Implement BTI with mozilla-backend.js based on firebug-service.js
 +
##* This will only last for FF4.1, it can be a hack job.
 +
# Milestone '''Script.js''': Firebug Lite script.js implemented with Firebug/Firefox sourcebox panel
 +
## port sourcebox panel to Lite
 +
## build new script panel based on sourcebox panel
 +
# Milestone '''Script/BTI''': in process use of BTI in Firefox
 +
## Insert BTI into script.js, calls mozilla-backend.js
 +
##* FBTests pass, the result will be first ship of BTI '''This is the proposed 1.7 target for 2010'''.
 +
# Milestone '''CrossUnit''': Unit tests via CrossFire
 +
## Implement Crossfire server to BTI calls
 +
## Implement Crossfire client from BTI calls
 +
## Drive unit tests end to end
 +
# Milestone '''Crossfox''': Crossfire from Firefox to Firefox
 +
## script.js to BTI to CrossFire Client to Server to mozilla-backend.js
 +
## FBTest pass
 +
## Fennec prototype
 +
#* the result will be first user value add and prepared for jsdv2
 +
# Milestone '''Modularity''': script.js usable in Firebug Lite and Firefox
 +
## Preliminary: modularity model.
 +
## script.js in Firebug Lite -> Firefox mozilla-backend.js
 +
# Milestone '''ChromeUnit''': Crossfire into V8
 +
## Implement V8 server (or not to start).
 +
## Drive unit tests into Chrome / V8
 +
# Milestone '''ChromeScript''': Firebug Lite JS debug in Chrome
 +
## Firebug Lite script.js drives Chrome/V8
 +
#* Result will be user value add Chrome JS debug with Firebug.
-
== How to Particiapate ==
+
== How to participate ==
*[http://groups.google.com/group/firebug-working-group/t/c6ffe85a9cc16990 Working Group Discussion on 1.7]
*[http://groups.google.com/group/firebug-working-group/t/c6ffe85a9cc16990 Working Group Discussion on 1.7]
*[http://groups.google.com/group/firebug Firebug newsgroup welcomes all comments]
*[http://groups.google.com/group/firebug Firebug newsgroup welcomes all comments]

Latest revision as of 03:44, 20 October 2010

Contents

[edit] Problems to be Solved by Refactoring

  • Prepare to support remote debugging for mobile and multiprocess browser
    • Server side will be headless
    • Client side will have no access to Firefox data
  • Allow simpler and more robust extensions
    • Javascript oriented loading, no XPCOM loader required
    • Isolation and concentration of extension code
  • Clean up expedient code and clarify the implementation
    • relation to platform window system
    • relation of panels and modules
    • prepare/exploit shift to jetpack

[edit] Proposed Changes

[edit] Separate Modules and Panels

Broadly speaking Mike Collins' architecture for remote Firebug puts the module code in the server and the panel code in the client (UI side). The Firebug 'context' object (TabContext.js) is passed over the wire between them using CrossFire.

The first step in that direction is to divide all of the source into module and panel files. For example we might have debuggerModule.js and debuggerPanel.js. Then firebug.js would be divided between module dispatch and panel dispatch (dispatchModules.js and dispatchPanels.js?). The API between these objects would be the API CrossFire would remote.

[edit] Issue: file names vs folders

I understand the natural appeal of module/debugger.js and panel/debugger.js vs debuggerModule.js and debuggerPanel.js. However in my experience one needs to write with one kind of module plus panel much more often than all of the panels or all of the modules. Creating a subdirectory for each feature, eg debugger/module.js make lots of small folders. Any scheme where the folder is used to disambiguate makes lots of tools hard to use because you end up with a lot of UI selections like "module.js" or "debugger.js" and you can't tell what it means. That is how I ended up with debuggerModule.js and debuggerPanel.js: unambiguous naming with the feature first so alphabetic sort groups by feature.

[edit] Components replaced by SharedObjects

We currently have 5 XPCOM components. We need to create two more, Firebug and DOMWindowWatcher (see below). Since these are all in Javascript, the XPCOM infrastructure only exists to arrange common access between Firebug windows. By creating a single SharedObject XPCOM component we can reduce the amount of boiler plate code and clarify the design. This will also prepare for in-place JS editing and dynamic update features in future.

[edit] Issue: SharedObject API

Leverage work by CommonJS

This would put us on the same path as jetpack proposals.

As far as I know the CommonJS, as well as Mozilla platform Components.utils.module, supports common code loading, but we want common object sharing. So there may be some additional work on API.

[edit] Recode TabWatcher -> DOMWindowWatcher

I think we now pretty much understand TabWatcher, but it is still very heuristic and relies on Firefox idiosyncrasies that can change. Chromebug has its own watcher and even more guesses about the platform. Let's replace all of that with a clean abstraction for nsIXULWindow and nsIDOMWindow lifetime event notifications. Then put it in a SharedObject so we only need one per application and we have clearer API.

This requires platform support

[edit] Issue: DOMWindowWatcher API

Ideally we would mimic/influence jetpack here, as they have a subset of the same problem.

[edit] Sandboxed Extension Loading

By re-applying the module loading technology we can create a jetpack-like environmental wrapper for Firebug extensions. The extensions would be slightly simpler because they would just be zip files. They would be slightly more robust, because they would be evaled in a scope that only contains Firebug.

[edit] Refactor debugger.js <-> firebug-service.js API

Ultimately we want debugger.js to split into a front-end and back-end, with the back-end implementing Crossfire's V8-like protocol. So a start is to shift work between debugger.js and firebug-service.js to be an V8-like API, and use firebug-service.js as an adapter between V8-like protocol and Mozilla jsd. (Note that JSDebugv2 aka js::dbg should have this kind of API).



[edit] Workplan items (not yet in order)

  1. Define a new interface Firebug.Middle
    • Functions equivalent to the Crossfire protocol
  2. Define new module mozilla-backend.js
    • Implements Firebug.Middle using jsd
  3. Define new module crossfire-client.js
    • Implements Firebug.Middle using Crossfire
  4. Define new Firefox extension Crossfire-Mozilla
    • Implements Crossfire server, calls mozilla-backend.js
  5. Define new Chrome extension Crossfire-Google
    • Implements Crossfire server, calls google-backend.js
  6. Reimplement debugger.js to calls into Firebug.Middle instead of fbs.
    • At load time Firebug.Middle is implemented using either mozilla-backend.js or crossfire-client.js
  7. Implement FBTest.Middle
    • js unit tests that call into Firebug.Middle
    • FBTest configuration to test mozilla-backend.js and crossfire-client.js looping through server

[edit] Detailed Work Plan For JS Reimplementation

Please ask jjb about any code in debugger.js or firebug-service.js that involves 'jsd' or 'fbs'. This code is all going away and we don't want to invest your time in understanding it more than needed.

  1. Milestone BTI: Interface, Unit Tests, firebug-service encapsulation
    1. Preliminary: move mozilla-specific code from debugger.js to fbs, split out script.js (front end).
    2. Define (initial) BrowserToolsInterface (BTI)
    3. Create unit tests for BTI
    4. Implement BTI with mozilla-backend.js based on firebug-service.js
      • This will only last for FF4.1, it can be a hack job.
  2. Milestone Script.js: Firebug Lite script.js implemented with Firebug/Firefox sourcebox panel
    1. port sourcebox panel to Lite
    2. build new script panel based on sourcebox panel
  3. Milestone Script/BTI: in process use of BTI in Firefox
    1. Insert BTI into script.js, calls mozilla-backend.js
      • FBTests pass, the result will be first ship of BTI This is the proposed 1.7 target for 2010.
  4. Milestone CrossUnit: Unit tests via CrossFire
    1. Implement Crossfire server to BTI calls
    2. Implement Crossfire client from BTI calls
    3. Drive unit tests end to end
  5. Milestone Crossfox: Crossfire from Firefox to Firefox
    1. script.js to BTI to CrossFire Client to Server to mozilla-backend.js
    2. FBTest pass
    3. Fennec prototype
    • the result will be first user value add and prepared for jsdv2
  6. Milestone Modularity: script.js usable in Firebug Lite and Firefox
    1. Preliminary: modularity model.
    2. script.js in Firebug Lite -> Firefox mozilla-backend.js
  7. Milestone ChromeUnit: Crossfire into V8
    1. Implement V8 server (or not to start).
    2. Drive unit tests into Chrome / V8
  8. Milestone ChromeScript: Firebug Lite JS debug in Chrome
    1. Firebug Lite script.js drives Chrome/V8
    • Result will be user value add Chrome JS debug with Firebug.

[edit] How to participate

Personal tools