DevTools/Features/Debugger/Notes

From MozillaWiki
Jump to: navigation, search

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

Remote Protocol Support

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

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

Remote Protocol Support

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

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

Protocol Support

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().
Retrieved from "https://wiki.mozilla.org/index.php?title=DevTools/Features/Debugger/Notes&oldid=307061"