Script Panel Refactoring
- Debugger Client API
- JS Debugger API Guide
- JS Debugger API Reference
- DevTools Debugger
- Remote Debugging Protocol
- Adopt JSD2 (get rid of all JSD1 APIs)
- Support remote debugging
JSD2 API Requirements
The following list summarizes the high-level features that Firebug needs to support. It should be verified that all the features can re-implemented on top of JSD2 before starting the refactoring.
- List of scripts available on selected tab (including static, events and evaluated scripts) including iframes →
- Stepping (into, over, out, resume, current line)
- Support for
- Support for breakpoints (add, remove, enable, disabled, conditional, list of existing breakpoints) →
- Recognize executable lines
- Dynamic eval in a frame (used e.g. by the Watch Side Panel when the debugger is halted) →
- Get stack frames (including passed arguments) →
- Scope chain variable exploring (with & closure scopes). It should be possible to see all values. →
- Break on next call
- Profiling (was part of JSD1)
- Tracking (break on) throw/catch/error →
- Tracking (monitoring) function calls
- Freezing page UI if debugger is halted (including timeouts, intervals and worker threads)
Not Ready in JSD2
- There is not source for evals.
- new Function scripts?
- Meta bug: Implement a script Debugger
- As soon as this one is fixed
- Profiling is unrelated to JSD2. What is the plan here?
- Tracking (break on) throw/catch/error; also what is the plan?
- Conditional breakpoints (bug 740825)
Script Panel Architecture
The Script panel needs to be built on top of JSD2, remote protocol and Firebug remote architecture. Remoting is already supported by HTTP Monitor and both components should share the same approaches and API.
Current Debugger Architecture
This section describes the current debugger architecture.
There are several layers/objects so, let's describe them step by step starting from the bottom.
- Backend: JSD1, FirebugService, Debugger
This layer represents JSD1 platform API. These API allows to implement script debuggers and represent direct competition to JSD2 API. Of course this layer should entirely disappear and should be replaced by JSD2.
Firebug service is implemented as js module on top of JSD1 layer. The object is called FBS and it's purpose is to wrap JSD1 API so, they are not directly accessed anywhere else. This layer also maintain list of registered debuggers (usually
Firebug.Debugger module) and fires various events to them (e.g. onToggleBreakpoint, onToggleMonitor, etc.) or execute theirs callback (e.g. onBreak, onFunctionCall, onError, onThrow, onScriptCreated, etc.)
- Activate/deactivate JSD in the browser. The activation is global for all current browser windows.
- Hook debugger events (interrupts, break on a breakpoint, etc.)
- Maintains list of registered debuggers (there is usually just one - Firebug debugger) and sends events to them.
- Manages nested event loop that is created for the debugger UI when page JS execution breaks.
- Sets/removes/enables/disables/saves/loads breakpoints
- Implements debugger stepping over/in/out/runUntil
- Monitors function calls
- Starts/stops profiling
- Tracks exceptions and errors (not working well)
- Tracks compiled scripts (not all of them)
This object is derived from
Firebug.Module and represents Firebug's debugger. It's also registered as a debugger into Firebug Service (FBS). This object should be the only one accessing FBS. It calls FBS API and receives various callbacks and events.
This object implements methods that can be used by the Script panel or other parts of Firebug (e.g. by those panels which implements BON).
Some examples of the API:
- evaluate, evaluateInCallingFrame
- breakNow, getCurrentStackTrace
- stepOver, stepInto, stepOut, runUntil, resume
- setBreakpoint, clearBrakpoint, etc.
- monitorFunction, unmonitorFunction
- monitorScript, unmonitorScript
- activateDebugger, deactivateDebugger
Implementation of these methods is based on FBS API.
There is also
Firebug.DebuggerListener that defines the interface used by FBS
- onStop, onResume, onThrow, onError, onScriptCreated (there is more onScriptCreated events)
Firebug.Debugger and the
ScriptPanel. The current implementation is in-process only so, based on direct
Firebug.Debugger API calls.
API of the tool is as follows:
- setBreakpoint, clearBreakpoint, enableBreakpoint, disableBreakpoint, isBreakpointDisabled, getBreakpointCondition
- onConnect, onDisconnect
- onStartDebugging, onStopDebugging
The BTI is used by Crossfire. Crossfire has the following structure:
Crossfire Panel ↓ Crossfire Module ↓ Crossfire Server ↓ Crossfire Socket Transport
When starting up it does the following.
- Register tools (e.g. console, inspector, ...)
- Start server
- Create socket transport
- Add BTI listener
- Set connection status
The Script panel sits at the top of the whole stack of layers/objects. It represents the debugger UI (a view + a controller). Implementation of this object is quite extensive since it also includes the source code view and viewpoort (see
The Script panel should never access the
Firebug.Debugger directly. It should always use the
So, for example, if the user clicks on the Breakpoint bar, the action is handled by the Script panel, forwarded to the
Firebug.Debugger, which forwards it to
FBS is using JSD1 API to set the breakpoint.
There are other side panels (breakpoints, watch, stack), which are synchronized automatically with the Script panel. They should all use
The synchronization happens through basic Firebug mechanisms like, updateSelection and updateLocation.