Firebug 1.9: Architecture Refactoring

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Created page with "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...")
Line 1: Line 1:
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''  
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 ===
+
== Remotable Panels ==
The Script panel was partially ported to use the asynchronous BTI interface in Firebug 1.8.
The Script panel was partially ported to use the asynchronous BTI interface in Firebug 1.8.
Line 8: Line 8:
-
=== Recode TabWatcher -> DOMWindowWatcher ===
+
== Recode TabWatcher -> DOMWindowWatcher ==
-
''This section has been carried over from [[Firebug_1.7:_Architecture_Refactoring]] and [[Firebug_1.8:_Architecture_Refactoring]] -mcollins''
+
''This section has been carried over from [[Firebug_1.7:_Architecture_Refactoring]] and [[Firebug_1.8:_Architecture_Refactoring]] --mcollins''
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.
Line 16: Line 16:
This requires [http://getfirebug.com/wiki/index.php/Firebug_1.6_Feature_Wish_List#TabWatcher_refactoring platform support]
This requires [http://getfirebug.com/wiki/index.php/Firebug_1.6_Feature_Wish_List#TabWatcher_refactoring platform support]
-
==== Issue: DOMWindowWatcher API ====
+
=== Issue: DOMWindowWatcher API ===
Ideally we would mimic/influence jetpack here, as they have a subset of the same problem.
Ideally we would mimic/influence jetpack here, as they have a subset of the same problem.

Revision as of 21:24, 20 July 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

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 --mcollins

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

Issue: DOMWindowWatcher API

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

Personal tools