Firebug 1.9: Architecture Refactoring

From FirebugWiki
Revision as of 13:25, 7 November 2011 by Sebastianz (Talk | contribs) (Fixed internal links)

Jump to: navigation, search

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

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

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

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

Crossfire Remote Client approach

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.