Firebug 1.7: Mozilla Backend

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Created page with 'Mozilla back-end represents an adapter between V8 like protocol and Mozilla JSD. This adapter lives in Firebug and implements BTI interface. This adapter should replace ''firebug…')
(Test Cases)
 
(2 intermediate revisions not shown)
Line 8: Line 8:
-
==Implementation Details==
+
==Implementation==
Corresponding BTI objects:
Corresponding BTI objects:
Line 21: Line 21:
[[File:Bti-uml.png]]
[[File:Bti-uml.png]]
-
''What is the JavaScriptContext in the context of Firebug architecture?''
+
''Can you describe relations among BTI objects, which are not on the picture?''
-
''Can you describe relations among BTI objects?''
+
Line 31: Line 30:
''Where is Firebug.Debugger in this concept?''
''Where is Firebug.Debugger in this concept?''
 +
 +
Firebug.Debugger listens for events and stores information from the events on the context object. So for example it will listen for onSourceFileCreated (or rather the BTI equivalent) and append the information about the new compilation unit on the context.
===Connect===
===Connect===
Connect to the browser.
Connect to the browser.
 +
 +
''What object in Firebug infrastructure should be responsible for this?''
Line 40: Line 43:
Get list of all available contexts in the connected browser.
Get list of all available contexts in the connected browser.
-
===Compilation Unit===
+
''How TabWatcher is related to the mozilla-backend implementation?
 +
 
 +
If we think of mozilla-backend as the entire non-UI part of Firebug, then TabWatcher is part of it. TabWatcher will generate events just as it does in 1.6. Firebug.Debugger will forward some of those events through BTI.
 +
 
 +
 
 +
===Compilation Units===
Get list of all compilation units for given context.
Get list of all compilation units for given context.
 +
 +
[[File:Mozilla-backend-getcompilationunits.png]]
 +
 +
This scenario represents initialization of the ''location-list'' that is available on the Script panel toolbar. Displayed popup menu is initialized when the user clicks on the toolbar button.
 +
 +
''JJB: Firebug.Debugger will get onSourceFileCreated just like 1.6. It will store info in context like 1.6. Then it will fire an event into BTI. The front end will get the event from BTI and store info in its panel. So I think we need the get-all-compilation units only for re-sync. ''
 +
===Get Source===
===Get Source===
-
Get source code (range) for given compilation unit.
+
Get source code (range) of given compilation unit.
 +
 
 +
[[File:Mozilla-backend-getsource.png]]
 +
 
 +
This scenario happens typically when the user changes the location of the Script panel (e.g. wants to see another script file). The <code>getSource</code> method can be also used to get just part of the source (a ''range''), which is used when the user scrolls the panel content. This allows to load only visible portion of the file and optimize networks traffic in case of remote debugging.
 +
 
===Set Breakpoint===
===Set Breakpoint===
Line 51: Line 71:
[[File:Mozilla-backend-setbreakpoint.png]]
[[File:Mozilla-backend-setbreakpoint.png]]
-
''Where the list of compilation units is stored?''
+
The ''Script'' panel is always using ''toggleBreakpoint'' call, which is consequently transformed into ''setBreakpoint'' or ''removeBreakpoint'' (depends on existence of the breakpoint).
-
''What is the event/callback that allows to collect all compilation units?''
+
''Is the list of compilation units still stored in the BrowserContext?'' YES
 +
 
 +
''What is the event/callback that allows to collect all compilation units?'' See above, it should get the compilation units as they are created.
===Get Stack Trace===
===Get Stack Trace===
-
Get stack trace (aka backtrace) when a breakpoint hits.
+
Get stack-trace (aka backtrace) when a breakpoint hits.
 +
 
 +
[[File:Mozilla-backend-getstacktrace.png]]
 +
 
 +
This scenario is executed when the debuggers is hanging on a breakpoint and the user shows the ''CallstackPanel'' to see the current stack-trace.
 +
 
 +
''What is the JavaScriptContext here in Firebug infrastructure?''  I guess the JS global object
 +
 
===Debugger Step===
===Debugger Step===
Perform a debugger step (step over, step into, continue)
Perform a debugger step (step over, step into, continue)
 +
 +
''I don't see how to perform this action using BTI''
 +
 +
''Should this be done through an event?''
 +
===Disconnect===
===Disconnect===
Disconnect from the debugger
Disconnect from the debugger
 +
 +
''The same question as in the Connect case''
 +
 +
==Tests==
 +
In order to make sure the architecture is suitable also for remote debugging (the goal) there should be proper unit test written for it.
 +
 +
''TODO: describe architecture of these tests''
 +
 +
''What mockup objects will be necessary here?''

Latest revision as of 22:07, 5 November 2010

Mozilla back-end represents an adapter between V8 like protocol and Mozilla JSD. This adapter lives in Firebug and implements BTI interface. This adapter should replace firebug-service in Firebug 1.7.

Contents

[edit] Resources


[edit] Implementation

Corresponding BTI objects:

  • BTI.BrowserFirebug firebug.js
  • BTI.CompilationUnitFirebug.SourceFile sourceFile.js
  • BTI.StackFrameFBL.StackFrame lib.js
  • BTI.BreakpointFirebug.Breakpoint breakpoint.js
  • BTI.BrowserContextFirebug.TabContext tabContext.js
  • BTI.JavaScriptContext → ?

Bti-uml.png

Can you describe relations among BTI objects, which are not on the picture?


[edit] Test Cases

Exploration of some real world scenarios that happens when debugging a web application. These scenarios describe in-process usage of the firebug-service through a BTI adapter. The basic concept is as follows:

Firebug UI (Script Panel) → BTI → FBS → JSD

Where is Firebug.Debugger in this concept?

Firebug.Debugger listens for events and stores information from the events on the context object. So for example it will listen for onSourceFileCreated (or rather the BTI equivalent) and append the information about the new compilation unit on the context.


[edit] Connect

Connect to the browser.

What object in Firebug infrastructure should be responsible for this?


[edit] Get Contexts

Get list of all available contexts in the connected browser.

How TabWatcher is related to the mozilla-backend implementation?

If we think of mozilla-backend as the entire non-UI part of Firebug, then TabWatcher is part of it. TabWatcher will generate events just as it does in 1.6. Firebug.Debugger will forward some of those events through BTI.


[edit] Compilation Units

Get list of all compilation units for given context.

Mozilla-backend-getcompilationunits.png

This scenario represents initialization of the location-list that is available on the Script panel toolbar. Displayed popup menu is initialized when the user clicks on the toolbar button.

JJB: Firebug.Debugger will get onSourceFileCreated just like 1.6. It will store info in context like 1.6. Then it will fire an event into BTI. The front end will get the event from BTI and store info in its panel. So I think we need the get-all-compilation units only for re-sync.


[edit] Get Source

Get source code (range) of given compilation unit.

Mozilla-backend-getsource.png

This scenario happens typically when the user changes the location of the Script panel (e.g. wants to see another script file). The getSource method can be also used to get just part of the source (a range), which is used when the user scrolls the panel content. This allows to load only visible portion of the file and optimize networks traffic in case of remote debugging.


[edit] Set Breakpoint

Set a breakpoint in given compilation unit.

Mozilla-backend-setbreakpoint.png

The Script panel is always using toggleBreakpoint call, which is consequently transformed into setBreakpoint or removeBreakpoint (depends on existence of the breakpoint).

Is the list of compilation units still stored in the BrowserContext? YES

What is the event/callback that allows to collect all compilation units? See above, it should get the compilation units as they are created.


[edit] Get Stack Trace

Get stack-trace (aka backtrace) when a breakpoint hits.

Mozilla-backend-getstacktrace.png

This scenario is executed when the debuggers is hanging on a breakpoint and the user shows the CallstackPanel to see the current stack-trace.

What is the JavaScriptContext here in Firebug infrastructure? I guess the JS global object


[edit] Debugger Step

Perform a debugger step (step over, step into, continue)

I don't see how to perform this action using BTI

Should this be done through an event?


[edit] Disconnect

Disconnect from the debugger

The same question as in the Connect case

[edit] Tests

In order to make sure the architecture is suitable also for remote debugging (the goal) there should be proper unit test written for it.

TODO: describe architecture of these tests

What mockup objects will be necessary here?

Personal tools