DevTools/Features/Debugger: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
(Browser protocol integration.) |
||
| Line 54: | Line 54: | ||
== Basic Protocol Support == | == Basic Protocol Support == | ||
Basic implementation of the [[Remote Debugging Protocol]]. | |||
=== Protocol Transports === | === Protocol Transports === | ||
| Line 73: | Line 73: | ||
=== Actor registration API === | === Actor registration API === | ||
* Including maintenance of the actor tree. | * Including maintenance of the actor tree. | ||
=== Client API === | |||
* With appropriate client-side transport support. | |||
=== Debugging compartments === | === 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 thread's debugging actors. | * The debugger must be in a separate compartment from the debuggee, some sort of sandbox/new global-and-compartment for hosting a given thread's debugging actors. | ||
== 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? | |||
__NOTOC__ | __NOTOC__ | ||
Revision as of 01:10, 6 May 2011
| Feature | Status | ETA | Owner |
| DevTools/Features/Debugger | planning | YYYY-MM-DD | Kevin Dangoor |
Summary
Initial take on an integrated JavaScript debugger for Firefox.
Team
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 Manager: Kevin Dangoor (irc: kdangoor)
- Lead Developer: Dave Camp (irc: dcamp)
- Product Manager: Kevin Dangoor (irc: kdangoor)
- QA: TBD
- UX: TBD
- Security: TBD
Release Requirements
TBD
Next Steps
- scope out the project
Related Bugs & Dependencies
See the status page for the bug list and current status.
Designs
TBD
Planning
What follows is some plan-related sketching, please update appropriately.
Basic Protocol Support
Basic implementation of the Remote Debugging Protocol.
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).
- WebSockets (not needed for an initial implementation).
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.
Client API
- With appropriate client-side transport support.
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 thread's debugging actors.
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?