Difference between revisions of "Firebug 1.9: Architecture Refactoring"

From FirebugWiki
Jump to: navigation, search
m (Fixed internal links)
m
 
Line 10: Line 10:
 
== Recode TabWatcher -> DOMWindowWatcher ==
 
== Recode TabWatcher -> DOMWindowWatcher ==
  
''This section has been carried over from [[Firebug 1.7: Architecture_Refactoring]] and [[Firebug 1.8: Architecture Refactoring]]''
+
''This section has been carried over from [[Firebug 1.7: Architecture Refactoring]] and [[Firebug 1.8: Architecture Refactoring]]''
  
 
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.
 
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.

Latest revision as of 13:26, 7 November 2011

Firebug 1.8 took up a lot of the refactoring work that was initially planned for Firebug 1.7, but also had to adapt to Firefox's new faster release schedule. Firebug 1.9 takes up the refactoring work needed for the eventual shift to electrolysis

Remotable Panels[edit]

The Script panel was partially ported to use the asynchronous BTI interface in Firebug 1.8.

Honza is working on a prototype of the Net panel that would be remotable.


Recode TabWatcher -> DOMWindowWatcher[edit]

This section has been carried over from Firebug 1.7: Architecture Refactoring and Firebug 1.8: Architecture Refactoring

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.

Issue: DOMWindowWatcher API[edit]

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

Crossfire Remote Client approach[edit]

The Crossfire server receives events from TabWatcher such as "initContext" and "showContext" and sends them across the wire to the Crossfire client.

The standalone crossfire client does not have any tabs, therefore TabWatcher cannot work. Instead, in order for the Crossfire client to reuse Firebug's panels, upon receiving events from the Crossfire server, it needs to create a context object and perform the same actions that would be done by TabWatcher to trigger the panels to display.

Currently, this is accomplished on the client side by creating a new Context object which uses Firebug's TabContext as its prototype and then dispatching the appropriate events that TabWatcher normally would.