DevTools/Features/Debugger: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(48 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{| class="fullwidth-table"
{{FeatureStatus
|-
|Feature name=Debugger
| style="font-weight: bold; background: #DDD;" | Feature
|Feature stage=Complete
| style="font-weight: bold; background: #DDD;" | Status
|Feature status=In progress
| style="font-weight: bold; background: #DDD;" | ETA
|Feature version=Firefox 15
| style="font-weight: bold; background: #DDD;" | Owner
|Feature health=OK
|-
}}
<section begin="status" />
{{FeatureTeam
| [[DevTools/Features/Debugger]]
|Feature product manager=Kevin Dangoor
| {{StatusHealthy|status=planning (some prototype/initial impl work done)}}
|Feature feature manager=Rob Campbell
| 2011-05-13
|Feature lead engineer=Panos Astithas
| Kevin Dangoor
|Feature security lead=Mark Goodwin
<section end="status" />
|Feature qa lead=Ioana Budnar
|-
|Feature ux lead=Stephen Horlander
|}
|Feature additional members=Jason Orendorff, Jim Blandy, Victor Porof, Mihai Sucan
 
}}
== Summary ==
{{FeaturePageBody
 
|Feature overview=New JavaScript debugger.
Initial take on an integrated JavaScript debugger for Firefox.
|Feature users and use cases=JavaScript developers
 
}}
== Team ==
{{FeatureInfo
 
|Feature priority=P1
Have some thoughts on what you want out of a debugger? Inspiration on how to do it? Join us on #devtools on irc.mozilla.org
|Feature rank=6
 
|Feature roadmap=Developer Tools
* Jim Blandy (irc: jimb): Remote debugging protocol, jsd2.
|Feature list=Desktop
* Dave Camp (irc: dcamp): Firefox integration/UI, Remote debugging protocol.
|Feature engineering team=DevTools
* Jason Orendorff (irc: jorendorff): jsd2.
}}
 
{{FeatureTeamStatus
== Repositories ==
|Feature security status=sec-review-complete
* http://hg.mozilla.org/users/jblandy_mozilla.com/jsdbg2/ (JSD2)
|Feature security health=OK
* http://hg.mozilla.org/users/dcamp_campd.org/remote-debug/ (Remote Debugging Protocol/Firefox UI)
|Feature security notes=[[Security/Reviews/Firefox/RemoteDebug|Notes]]
 
|Feature qa status=work in progress
== Release Requirements ==
|Feature qa notes=[https://wiki.mozilla.org/index.php?title=DevTools/Features/Debugger/TestPlan Test Plan]
 
}}
TBD
 
== Next Steps ==
 
* scope out the project
 
== Related Bugs & Dependencies ==
 
See the [http://mozilla.github.com/devtools/2011/status.html#debugger status page] for the bug list and current status.
 
== Designs ==
== Designs ==
 
* [[JSInspector]]
TBD
* [[Remote_Debugging_Protocol]]
* [[DevTools/Features/Debugger/Notes]] has further implementation notes.


== Planning ==
== Planning ==
Line 58: Line 49:
* UI shell in firefox
* UI shell in firefox
* UI for stack traces (without arguments)
* UI for stack traces (without arguments)
* No iframe support just yet.


{| class="fullwidth-table"
{| class="fullwidth-table"
Line 77: Line 69:
| 3d
| 3d
| 5d
| 5d
|
| In remote-debug.
|-
|-
| Browser root actor/tab actors (not as thread-like actors)
| Browser root actor/tab actors (not as thread-like actors)
Line 86: Line 78:
| 2d
| 2d
| 4d
| 4d
|  
| In remote-debug.
|-
|-
| Protocol handler thread (socket transport)
| Protocol handler thread (socket transport)
Line 92: Line 84:
|
|
| dcamp
| dcamp
| 1d
| ?
| 1d
| ?
| 3d
| ?
|
| Put off for now.
|-
|-
| Debug Object creation and debuggerHook
| Debug Object creation and debuggerHook
Line 101: Line 93:
|
|
| jorendorff
| jorendorff
|
| 1d
|
| 1d
|
| 2d
| In jsdbg2 branch.
| In jsdb2
|-
|-
| Debug Object loader
| Debug Object loader
| JSD2ish
| JSD2ish
|
|
| jorendorff
| dcamp
|
|
|
|
|
|
| Similar to ctypes loader?
| In remote-debug
|-
|-
| Debug Object support for frame inspection  
| Debug Object support for frame inspection  
Line 131: Line 123:
| 2d
| 2d
| 4d
| 4d
|
| In remote-debug
|-
|-
| New execution model specification in the remote protocol
| New execution model specification in the remote protocol
Line 140: Line 132:
|
|
|
|
|
| Complete
|-
|-
| debuggerHook and "continue" exposed over remote protocol as specified.
| debuggerHook and "continue" exposed over remote protocol as specified.
Line 149: Line 141:
| 3d
| 3d
| 5d
| 5d
| Need to see what new spec looks like...
| In remote-debug.
|-
|-
| Client JS API (socket transport)
| Client JS API (socket transport)
Line 158: Line 150:
| 2d
| 2d
| 3d
| 3d
|
| In remote-debug.
|-
|-
| HTML UI shell per tab, in its own window
| HTML UI shell per tab, in its own window
Line 167: Line 159:
| 2d
| 2d
| 5d
| 5d
|
| In remote-debug
|-
|-
| UI responding to pauses (from debugger keyword)
| UI responding to pauses (from debugger keyword)
Line 176: Line 168:
| 2d
| 2d
| 4d
| 4d
|
| In remote-debug
|-
|-
| HTML Stack frame viewer (no locals/environment yet, just  
| HTML Stack frame viewer (no locals/environment yet, just  
Line 185: Line 177:
| 3d
| 3d
| 5d
| 5d
| In patch queue
|}
=== Property Viewer ===
* A simple property viewer, limited to viewing frame arguments for now.
{| class="fullwidth-table"
|-
| style="font-weight: bold; background: #DDD;" | Description
| style="font-weight: bold; background: #DDD;" | Area
| style="font-weight: bold; background: #DDD;" | Bug
| style="font-weight: bold; background: #DDD;" | Owner
| style="font-weight: bold; background: #DDD;" | Best
| style="font-weight: bold; background: #DDD;" | Likely
| style="font-weight: bold; background: #DDD;" | Worst
| style="font-weight: bold; background: #DDD;" | Status
|-
| Debug.Object.prototype.{proto, class, isFunction, name, getOwnPropertyDescriptor, getOwnPropertyNames}
| JSD2
|
| jorendorff/jimb
|
|
|
|
|-
| Primitive data grips for frame arguments
| Remote Proto
|
| dcamp
| 1d
| 1d
| 2d
| In remote-debug
|-
| Pause-lifetime object grips
| Remote Proto
|
| dcamp
| 1d
| 1d
| 2d
| In remote-debug
|-
| Thread-lifetime grip promotion
| Remote Proto
|
| dcamp
| 1d
| 2d
| 4d
| In remote-debug
|-
| Object grip enumeration
| Remote Proto
|
|
| dcamp
| 1d
| 2d
| 4d
| Waiting on jsd2
|-
| Property UI design
| UI
|
| past/dcamp
| 1d
| 1d
| 2d
|
|-
| Property Inspector UI
| UI
|
| past
| ?
| ?
| ?
| Split up as needed.
|}
|}


=== Source Viewer ===
=== Source Viewer ===
* Enough to visualize current line/stack frames/etc.
* Enough to visualize current line/stack frames/etc.
** Debug.Script.prototype.{url,startLine,length,getAllOffsets,getLineOffsets,getOffsetLine} - jorendorff
** Debug.Frame.prototype.{callee,script,offset} - jorendorff
* No source list yet, will only reflect sources handed to it in pause states.
* No source list yet, will only reflect sources handed to it in pause states.
* Can use normal view source/firebug method (loading from necko preferring the cache) for getting static script sources (in-document <script> etc).
* Can use normal view source/firebug method (loading from necko preferring the cache) for getting static script sources (in-document <script> etc).
* Needs the engine to provide sources for exotic script sources (eval/appendNode/etc)  
* Needs the engine to provide sources for exotic script sources (eval/appendNode/etc.)
* Very simple source viewer, improving the source viewer can happen outside the critical path.
* Very simple source viewer, improving the source viewer can happen outside the critical path.


=== Execution ===
=== Execution ===
* throw hook
* throw hook (Debug.hooks.throw) - jorendorff - Done.
* error hook
* error hook (Debug.hooks.error) - jorendorff
* resume
* resume (resumption values) - jorendorff - Done.
* step into/step out/finish
* work out low-level stepping support with the JM team - jorendorff/jimb
* implement Debug object stepping support (Debug.hooks.interrupt, Debug.Script.prototype.singleStepMode, etc.) - jorendorff
* step into/step out/finish - dcamp
 
In this timeframe, we also want to be able to:
* Show native calls on the stack - jorendorff, luke
* Show debugger frames on the stack - jorendorff
 
=== Frame Tree Support ===
* Debug.prototype.{add,remove}Debuggee() - jorendorff
* Frame tree support in the tab actors.


=== Environment/Property Viewer ===
=== Environment/Property Viewer ===


* JSD2 support:
* JSD2 support
** Debug.Object
** Debug.Frame.prototype.environment - jorendorff
** Debug.Environment
** Debug.Environment.prototype.{type,outerEnvironment,object, boundIdentifiers,getVariableDescriptor,findBinding} - jorendorff
* Protocol Support (actors for environments and objects)
** Pause-lifetime grips.
** Thread-lifetime grip promotion?  Maybe can wait?
* UI panel - simple tree view for objects?


By the time this milestone is complete, we'll have a somewhat competent debugger if you're willing to use debugger; statements instead of breakpoints.
By the time this milestone is complete, we'll have a somewhat competent debugger if you're willing to use debugger; statements instead of breakpoints.
Line 290: Line 369:
|
|
|}
|}
=== Frame Tree Support ===
* Debug.addDebuggee() - will need for frame tree support.
* Frame tree support in the tab actors.
== Basic Protocol Server ==
Basic implementation of the [[Remote Debugging Protocol]].
Much of this stuff will likely be dependent on xpcom components in the firefox implementation (nsIServerSocket, nsIThreadManager, etc).  As much as possible, we want to be able to retarget the implementation for projects outside of firefox, so this should be taken in to account.
None of this is implemented yet.
=== Protocol Transports ===
* Simple TCP socket protocol - Needed for remote debugging.
* Shouldn't need sockets for in-process debugging, can probably just post events directly to/from the handler thread.
* Need to figure out transport between chrome/content for e10s (See inter-process dispatch, below).
** Content processes will need their own root actor that can enumerate/dispatch to tabs hosted in their process.
** Presumably needs to use different APIs to list active tabs than we use in the chrome process (needs investigation).
** Ask content processes to start up debugging host (chrome process will have UI cues, will probably just forward those to content processes over messageManager).
* WebSockets (not needed for an initial implementation).
* How do we represent the actor tree across multiple connections
** Each connection is going to get its own debugger global/compartment in each thread.
=== Protocol Handler Thread ===
* Handles incoming protocol requests on a thread, needed to interrupt running script on other threads.
* Will handle transport IO as needed (for socket/websocket/etc transports).
* Handle inter-thread dispatching
** Dispatching incoming protocol messages to actors on the proper thread.
** An actor's parent or child might be on a different thread (for example when a browser tab actor might have a WebWorker actor as a child).  Releasing a parent actor needs to release children, including on the other threads.
* Handle inter-process dispatching
** Similar issues to inter-thread dispatch, but communicating to content processes using the debugging protocol.
=== Actor registration API ===
* Including maintenance of the actor tree.
=== Debugging compartments ===
* The debugger must be in a separate compartment from the debuggee, some sort of sandbox/new global-and-compartment for hosting a given connection's debugging actors on a thread.
== Protocol Client API ==
* With appropriate client-side transport support.
== Browser Protocol Integration ==
Firefox-specific integration of the remote protocol.
=== Root Actor ===
=== Content Tab Contexts ===
* Will need to maintain a list of compartments needing debugging for the document tree loaded in the tab.
* Manage lifetimes and notifications related to navigation.
* Tabs exposed as a thread-like actor (or maybe with an immediate child for the main thread running in that tab?)
=== Chrome Context ===
* For debugging firefox.
=== WebWorker/ChromeWorker ===
* Related to inter-thread dispatch above.  Likely to require some platform work on webworkers to get them to load the debug protocol implementation on startup?
== UI Shell ==
* For basic debugging, want a single debugger UI per tab
** Docked
** Separate Window
* Unconnected debugging shell for connecting to remote debugging targets
** Always separate window.
* Shell for debugging chrome.
* Until we get some spidermonkey improvements, we're going to need a reload to debug correctly
** XXX jimb/jorendorff: please review this claim.
** Ability to recompile scripts with debug support.
** Firebug currently needs to observe creation to infer information (see elsewhere about script information)
** Debugger UI per tab, either docked or separate window
* Connection management.
== Stack Traces ==
=== JSD2 support ===
* [[Debug_Object#Debug.Frame]]
* Mostly (?) implemented in jsdbg2 branch.
=== Remote Protocol Support ===
* [[Remote_Debugging_Protocol#Listing_Stack_Frames]]
* Not implemented.
=== UI ===
* Not implemented.
=== UI Notes: Other Debuggers ===
Firebug
* Stack frame shows function name/source/line num, args
* Expand frames to view function args
* Selecting stack frame moves source view
* Right-clicking stack frames allowed viewing properties of function objects in the DOM tab.
* Breadcrumb view of the stack in the source view.
Chrome
* Stack frame shows function name/source/line
* Scope variables/environment in a different pane (see Environments)
* Selecting stack frame moves source view
== Lexical Environments ==
=== JSD2 ===
* [[Debug_Object#Debug.Environment]]
* Not implemented.
* (Uncategorized thought: frame.eval() is going to fail if it refers to a value that was optimized out of a closure.  Jimb points out that the engine could conceivably notify that the value should have been there but isn't)
=== Remote Protocol Support ===
* [[Remote_Debugging_Protocol#Lexical_Environments]]
* Not implemented.
=== UI ===
* Not implemented.
=== UI Notes: Other Debuggers ===
Firebug:
* XXX: I couldn't find where/if firebug exposes lexical scopes.
Chrome:
* Scope chain exposed as a list, property viewers for each scope.
== Execution Control ==
=== JSD2 ===
* [[Debug_Object#Resumption_Values]]
* [[Debug_Object#Debug.Script]] (specifically "singleStepMode")
* Not implemented?
=== Remote Protocol Support ===
* [[Remote_Debugging_Protocol#Interacting_with_Thread-Like_Actors]]
* jimb mentioned on irc being unhappy with the pause/resume protocol, may need another spec iteration.
* Not implemented.
=== Implementation Notes ===
(this is a mess, ignore for now).
Pause Reasons:
* stepped
* pre-call
* pre-return
* pre-eval?
Breaking on exception:
* pre-throw/caught/uncaught
=== UI ===
Not implemented.
=== UI Notes ===
Chrome
* Allows toggling of throw/caught/uncaught pause reasons during execution.
* Pause/Continue/Step Over/Step Into/Step Out (finish)
Firebug
* Has Rerun/Continue/Step Into/Step Over/Step Out (finish)
* Calls pause Break-on-next (makes a bit more sense when spinning the event loop, and it can't actually pause?).
== Breakpoints ==
=== JSD2 ===
* [[Debug_Object#The_Debug_Object]]
* setBreakpoint/clearBreakpoint/clearAllBreakpoints
* Not implemented.
=== Protocol Support ===
* [[Remote_Debugging_Protocol#Breakpoints]]
* Not implemented.
* Looks like the protocol implementation will need to refcount breakpoints on the debug object (which has one-breakpoint-per-line) to support multiple breakpoints on a given line (potentially with different conditions).
* The protocol will also aggregate breakpoints on multiple scripts (for example, if the same script is loaded twice, there might be two scripts covering the same source location) for a given breakpoint actor.
* Protocol should be extended with breakpoint conditions?
=== UI ===
Not implemented.
=== UI Notes ===
Let's make sure you can edit a breakpoint's condition in the breakpoint list.
Firebug:
* Firebug uses disabled breakpoints to prevent stopping at debugger keywords.
* Breakpoint list:
** function name
** source name/line number
** text of the source at that line
** Checkbox to enable/disable
** X button to delete.
* Seems to only allow one breakpoint per source line (at least from the ui).
Chrome:
* Breakpoint list:
** source name/line number
** text of the source at that line
** Checkbox to enable/disable
** Context menu to delete.
* Can "edit" (change a breakpoint's condition) a breakpoint from the source gutter, can't do that from the breakpoint list
* Seems to only allow one breakpoint per source line (at least from the UI).
== Source List ==
https://bugzilla.mozilla.org/show_bug.cgi?id=637572
* This bug is important for proper handling of eval/event handlers/etc.  Important early on, script loaders are common practice.
* Need to resource fixing this bug asap.
Firebug does a lot a crazy stuff to get scripts right for all origins (inline, eval, document.write, dom-appended script tags, etc).  We'd prefer to avoid this with 637572, and we might be weaker than firebug with the more exotic sources in the meantime.  XXX: Need to figure out exactly how much weaker.
Script sources:
* Static/inline scripts
** Pretty well-understood
* Eval
* Event handlers
* document.write script tags
** Can mess with line numbers.
* DOM injection of script tags/innerHTML
=== JSD2 support ===
* [[Debug_Object#Debug.Script]]
* [[Debug_Object#Debugging_hooks]] - newScript, specifically.
* Not implemented.
=== Protocol Support ===
* [[Debug_Object#Debugging_hooks]]
* Not implemented.
=== UI ===
=== UI Notes ===
Chrome:
* Eval's show up in the source list as "(program)"
* Static sources are listed by basename (no disambiguation).
* Maintains a back-forward list for the source viewer.
Firebug:
* Shows evals
** Given a name based on parent url (foo.html/eval/seq/1)
* Event handlers
** Don't seem to show up unless you actually cause execution to stop in them (afaict)?
** Given a name based on its parent url (foo.html/event/seq/1)
* Static source listed by basename with path headers for disambiguation.
* Maintains back-forward list for the source viewer.
== Source Viewer ==
=== JSD2 Support ===
* Would be nice to have originalSource support in spidermonkey/JSD2, but none is currently specced/planned.
=== Protocol Support ===
* In the meantime, we can do protocol-side with necko (like firebug does currently).
* For the in-process content case, might want shortcut using the protocol.
* This needs spec thought.
=== UI ===
=== UI Notes ===
Chrome:
* Line numbers/breakpoints/current line in gutter.
* Syntax highlighting
* Left-click in gutter sets/unsets breakpoint
* Right-click in gutter brings up a context menu with:
** Continue to here
** Add/Remove Breakpoint
** Add Conditional Breakpoint
** Disable Breakpoint
Firebug:
* Line numbers/breakpoints/current line in gutter.
* Line numbers seem to be colored by executability.
* No syntax highlighting
* Left-click in gutter sets/unsets breakpoint.
* Right-click in gutter sets conditional breakpoint.
== Event Handling ==
* While stopped at the debugger spinning an event loop, we want to prevent event handlers from being processed by content.
* Right now that's done by firebug using nsDOMWindowUtils.suppressEventHandling().
* Prevents any interaction with the page at all:  no selecting, scrolling, etc.
* Not sure how it interacts with XHR?  XHR should be queued somehow.
* Would be nice to be able to select/scroll/etc on a stopped page, without allowing content handlers to run.
* Summary events would need to be sent for scrolling/etc, similar to the focus events currently sent by UnsupressEventHandling().
__NOTOC__
__NOTOC__
[[Category:Features]]
[[Category:Firefox]]

Latest revision as of 13:40, 30 August 2012

Please use "Edit with form" above to edit this page.

Status

Debugger
Stage Complete
Status In progress
Release target Firefox 15
Health OK
Status note `

{{#set:Feature name=Debugger

|Feature stage=Complete |Feature status=In progress |Feature version=Firefox 15 |Feature health=OK |Feature status note=` }}

Team

Product manager Kevin Dangoor
Directly Responsible Individual Rob Campbell
Lead engineer Panos Astithas
Security lead Mark Goodwin
Privacy lead `
Localization lead `
Accessibility lead `
QA lead Ioana Budnar
UX lead Stephen Horlander
Product marketing lead `
Operations lead `
Additional members Jason Orendorff, Jim Blandy, Victor Porof, Mihai Sucan

{{#set:Feature product manager=Kevin Dangoor

|Feature feature manager=Rob Campbell |Feature lead engineer=Panos Astithas |Feature security lead=Mark Goodwin |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=Ioana Budnar |Feature ux lead=Stephen Horlander |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Jason Orendorff, Jim Blandy, Victor Porof, Mihai Sucan }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

New JavaScript debugger.

2. Users & use cases

JavaScript developers

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=New JavaScript debugger. |Feature users and use cases=JavaScript developers |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority P1
Rank 6
Theme / Goal `
Roadmap Developer Tools
Secondary roadmap `
Feature list Desktop
Project `
Engineering team DevTools

{{#set:Feature priority=P1

|Feature rank=6 |Feature theme=` |Feature roadmap=Developer Tools |Feature secondary roadmap=` |Feature list=Desktop |Feature project=` |Feature engineering team=DevTools }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-complete Notes
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance work in progress Test Plan
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-complete |Feature security health=OK |Feature security notes=Notes |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=work in progress |Feature qa notes=Test Plan |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Designs

Planning

What follows is some plan-related sketching, please update appropriately. List of milestones/sprints is roughly in order.

Bootstrapping/Stack Traces

  • Working remote protocol, exposing stack frames with JSD2.
  • Relying on debugger statement, no breakpoints.
  • Only "continue" after stopping in debugger.
  • UI shell in firefox
  • UI for stack traces (without arguments)
  • No iframe support just yet.
Description Area Bug Owner Best Likely Worst Status
Debugging global/Root actor registration/Socket Listener Remote Proto dcamp 2d 3d 5d In remote-debug.
Browser root actor/tab actors (not as thread-like actors) Browser Proto dcamp 2d 2d 4d In remote-debug.
Protocol handler thread (socket transport) Remote Proto dcamp ? ? ? Put off for now.
Debug Object creation and debuggerHook JSD2 jorendorff 1d 1d 2d In jsdb2
Debug Object loader JSD2ish dcamp In remote-debug
Debug Object support for frame inspection JSD2 jorendorff type, this, older, live, callee, generator, arguments complete.
Debug Object support for the toplevel globals in tab actor - debuggerHook spawning a nested event loop. Browser Proto dcamp 2d 2d 4d In remote-debug
New execution model specification in the remote protocol Remote Proto jimb Complete
debuggerHook and "continue" exposed over remote protocol as specified. Remote Proto dcamp 3d 3d 5d In remote-debug.
Client JS API (socket transport) UI Shell dcamp 1d 2d 3d In remote-debug.
HTML UI shell per tab, in its own window UI Shell dcamp 2d 2d 5d In remote-debug
UI responding to pauses (from debugger keyword) Execution Handling dcamp 2d 2d 4d In remote-debug
HTML Stack frame viewer (no locals/environment yet, just Execution Handling dcamp 2d 3d 5d In patch queue

Property Viewer

  • A simple property viewer, limited to viewing frame arguments for now.
Description Area Bug Owner Best Likely Worst Status
Debug.Object.prototype.{proto, class, isFunction, name, getOwnPropertyDescriptor, getOwnPropertyNames} JSD2 jorendorff/jimb
Primitive data grips for frame arguments Remote Proto dcamp 1d 1d 2d In remote-debug
Pause-lifetime object grips Remote Proto dcamp 1d 1d 2d In remote-debug
Thread-lifetime grip promotion Remote Proto dcamp 1d 2d 4d In remote-debug
Object grip enumeration Remote Proto dcamp 1d 2d 4d Waiting on jsd2
Property UI design UI past/dcamp 1d 1d 2d
Property Inspector UI UI past ? ? ? Split up as needed.

Source Viewer

  • Enough to visualize current line/stack frames/etc.
    • Debug.Script.prototype.{url,startLine,length,getAllOffsets,getLineOffsets,getOffsetLine} - jorendorff
    • Debug.Frame.prototype.{callee,script,offset} - jorendorff
  • No source list yet, will only reflect sources handed to it in pause states.
  • Can use normal view source/firebug method (loading from necko preferring the cache) for getting static script sources (in-document <script> etc).
  • Needs the engine to provide sources for exotic script sources (eval/appendNode/etc.)
  • Very simple source viewer, improving the source viewer can happen outside the critical path.

Execution

  • throw hook (Debug.hooks.throw) - jorendorff - Done.
  • error hook (Debug.hooks.error) - jorendorff
  • resume (resumption values) - jorendorff - Done.
  • work out low-level stepping support with the JM team - jorendorff/jimb
  • implement Debug object stepping support (Debug.hooks.interrupt, Debug.Script.prototype.singleStepMode, etc.) - jorendorff
  • step into/step out/finish - dcamp

In this timeframe, we also want to be able to:

  • Show native calls on the stack - jorendorff, luke
  • Show debugger frames on the stack - jorendorff

Frame Tree Support

  • Debug.prototype.{add,remove}Debuggee() - jorendorff
  • Frame tree support in the tab actors.

Environment/Property Viewer

  • JSD2 support
    • Debug.Frame.prototype.environment - jorendorff
    • Debug.Environment.prototype.{type,outerEnvironment,object, boundIdentifiers,getVariableDescriptor,findBinding} - jorendorff

By the time this milestone is complete, we'll have a somewhat competent debugger if you're willing to use debugger; statements instead of breakpoints.

Source Selector

  • JSD2 support
    • newScript hook
    • enumerate scripts? Maybe not - since we need currently need to reload anyway to recompile scripts for debugging, might be ok to always just watch the newScript hook.
  • Protocol support
    • new script notification.
  • UI support: dropdown of available scripts, triggering loads in the source viewer.

Breakpoints

  • JSD2 support.
  • Protocol-side breakpoints will set physical breakpoints at each script (including newly-added scripts)
  • Need to work out breakpoint persistence across reloads (needs to be done early enough to catch scripts run during the load).
  • Set breakpoints in the source gutter
  • Set breakpoints from a command line (?)
  • Disable/Enable/Delete breakpoints

More Milestones

In no particular order...

  • Web Worker debugging (might not be needed for an initial release, but would be really nice)
  • Chrome debugging (probably not be needed for an initial release)

Floating Tasks

Here are a few tasks that I haven't slotted into any specific milestone, and could be tackled separately alongside the other milestones. At least some of these would block a final release of a capable debugger.


Description Area Bug Owner Best Likely Worst Status
E10S content process support Remote Proto dcamp? 1w 3w 2w
Improved script origin information JSD2 bug 637572 jimb
Waive slow script dialog (jorendorff was seeing them after resuming) JSD2
Improve source viewer (after basic source viewer is added) Firefox UI No Owner