|
# Remote Debugging Protocol
The Mozilla debugging protocol allows a debugger to connect to a browser, discover what sorts of things are present to debug or inspect, select JavaScript threads to watch, and observe and modify their execution. The protocol provides a unified view of JavaScript, DOM nodes, CSS rules, and the other technologies used in client-side web applications. The protocol ought to be sufficiently general to be extended for use with other sorts of clients (profilers, say) and servers (mail readers; random XULrunner applications).
All communication between debugger (client) and browser (server) is in the form of JSON objects. This makes the protocol directly readable by humans, capable of graceful evolution, and easy to implement using stock libraries. In particular, it should be easy to create mock implementations for testing and experimentation.
The protocol operates at the JavaScript level, not at the C++ or machine level, and assumes that the JavaScript implementation itself is healthy and responsive. The JavaScript program being executed may well have gone wrong, but the JavaScript implementation's internal state must not be corrupt. Bugs in the implementation may cause the debugger to fail; bugs in the interpreted program must not.
## General Conventions
### Actors
An **actor** is something on the server that can exchange JSON packets with the client. Every packet from the client specifies the actor to which it is directed, and every packet from the server indicates which actor sent it.
Each server has a root actor, with which the client first interacts. The root actor can explain what sort of thing the server represents (browser; mail reader; etc.), and enumerate things available to debug: tabs, chrome, and so on. Each of these, in turn, is represented by an actor to which requests can be addressed. Both artifacts of the program being debugged, like JavaScript objects and stack frames, and artifacts of the debugging machinery, like breakpoints and watchpoints, are actors with whom packets can be exchanged.
For example, a debugger might connect to a browser, ask the root actor to list the browser's tabs, and present this list to the developer. If the developer chooses some tabs to debug, then the debugger can send `attach` requests to the actors representing those tabs, to begin debugging.
Actor names are JSON strings, containing no spaces or colons. The name of the root actor is `"root"`.
To allow the server to reuse actor names and the resources they require, actors have limited lifetimes. All actors in a server form a tree, whose root is the root actor. Closing communications with an actor automatically closes communications with its descendants. For example, the actors representing a thread's stack frames are children of the actor representing the thread itself, so that when a debugger detaches from a thread, which closes the thread's actor, the frames' actors are automatically closed. This arrangement allows the protocol to mention actors liberally, without making the client responsible for explicitly closing every actor that has ever been mentioned.
When we say that some actor *A* is a child of some actor *B*, we mean that *A* is a direct child of *B*, not a grandchild, great-grandchild, or the like. Similarly, **parent** means "direct parent". We use the terms **ancestor** and **descendent** to refer to those looser relationships.
The root actor has no parent, and lives as long as the underlying connection to the client does; when that connection is closed, all actors are closed.
Note that the actor hierarchy does not, in general, correspond to any particular hierarchy appearing in the debuggee. For example, although web workers are arranged in a hierarchy, the actors representing web worker threads are all children of the root actor: one might want to detach from a parent worker while continuing to debug one of its children, so it doesn't make sense to close communications with a child worker simply because one has closed communications with its parent.
*(We are stealing the "actor" terminology from Mozilla's IPDL, to mean, roughly, "things participating in the protocol". However, IPDL does much more with the idea than we do: it treats both client and server as collections of actors, and uses that detail to statically verify properties of the protocol. In contrast, the debugging protocol simply wants a consistent way to indicate the entities to which packets are directed.)*
### Packets
The protocol is carried by a reliable, bi-directional byte stream; data sent in both directions consists of JSON objects, called packets. A packet is a top-level JSON object, not contained inside any other value.
Every packet sent from the client has the form:
```
{ "to":actor, "type":type, ... }
```
where `actor` is the name of the actor to whom the packet is directed and `type` is a string specifying what sort of packet it is. Additional properties may be present, depending on `type`.
Every packet sent from the server has the form:
```
{ "from":actor, ... }
```
where `actor` is the name of the actor that sent it. The packet may have additional properties, depending on the situation.
If a packet is directed to an actor that no longer exists, the server sends a packet to the client of the following form:
```
{ "from":actor, "error":"noSuchActor" }
```
where `actor` is the name of the non-existent actor. (It is strange to receive messages from actors that do not exist, but the client evidently believes that actor exists, and this reply allows the client to pair up the error report with the source of the problem.)
Clients should silently ignore packet properties they do not recognize. We expect that, as the protocol evolves, we will specify new properties that can appear in existing packets, and experimental implementations will do the same.
### Common Patterns of Actor Communication
Each type of actor specifies which packets it can receive, which it might send, and when it can do each. Although in principle these interaction rules could be complex, in practice most actors follow one of two simple patterns:
* **Request/Reply**: Each packet sent to the actor ("request") elicits a single packet in response ("reply").
* **Request/Reply/Notify**: Like Request/Reply, but the actor may send packets that are not in response to any specific request ("notification"), perhaps announcing events that occur spontaneously in the debuggee.
These patterns are described in more detail below.
Some actors require more complicated rules. For example, the set of packets accepted by a [Thread-like actor](#interacting-with-thread-like-actors) depends on which one of four states it occupies. The actor may spontaneously transition from one state to another, and not all state transitions produce notification packets. Actors like this require careful specification.
#### The Request/Reply Pattern
In this specification, if we call a packet a **request**, then it is a packet sent by the client, which always elicits a single packet from the actor in return, the **reply**. These terms indicate a simple pattern of communication: the actor processes packets in the order they are received, and the client can trust that the *i*'th reply corresponds to the *i*'th request.
An [error reply packet](#error-packets) from a request/reply actor constitutes a reply.
Note that it is correct for a client to send several requests to a request/reply actor without waiting for a reply to each request before sending the next; requests can be pipelined. However, as the pending requests consume memory, the client should ensure that only a bounded number of requests are outstanding at any one time.
#### The Request/Reply/Notify Pattern
Some actors follow the request/reply pattern, but may also send the client ***notification*** packets, not in reply to any particular request. For example, if the client sends the root actor a `["listTabs"](#listing-browser-tabs)` request, then the root actor sends a reply. However, since the client has now expressed an interest in the list of open tabs, the root actor may subsequently send the client a `"tabListChanged"` notification packet, indicating that the client should re-fetch the list of tabs if it is interested in the latest state.
There should be a small upper bound on the number of notification packets any actor may send between packets received from the client, to ensure that the actor does not flood the client. In the example above, the root actor sends at most one `"tabListChanged"` notification after each `"listTabs"` request.
#### Error Packets
Any actor can reply to a packet it is unable to process with an **error reply** of the form:
```
{ "from":actor, "error":name, "message":message }
```
where *name* is a JSON string naming what went wrong, and *message* is an English error message. Error *names* are specified by the protocol; the client can use the name to identify which error condition arose. The *message* may vary from implementation to implementation, and should only be displayed to the user as a last resort, as the server lacks enough information about the user interface context to provide appropriate messages.
If an actor receives a packet whose type it does not recognize, it sends an error reply of the form:
```
{ "from":actor, "error":"unrecognizedPacketType", "message":message }
```
where *message* provides details to help debugger developers understand what went wrong: what kind of actor actor is; the packet received; and so on.
If an actor receives a packet which is missing needed parameters (say, an `"autocomplete"` packet with no `"text"` parameter), it sends an error reply of the form:
```
{ "from":actor, "error":"missingParameter", "message":message }
```
where *message* provides details to help debugger developers fix the problem.
If an actor receives a packet with a parameter whose value is inappropriate for the operation, it sends an error reply of the form:
```
{ "from":actor, "error":"badParameterType", "message":message }
```
where *message* provides details to help debugger developers fix the problem. (Some packets' descriptions specify more specific errors for particular circumstances.)
### Grips
A grip is a JSON value that refers to a specific JavaScript value in the debuggee. Grips appear anywhere an arbitrary value from the debuggee needs to be conveyed to the client: stack frames, object property lists, lexical environments, `paused` packets, and so on.
For mutable values like objects and arrays, grips do not merely convey the value's current state to the client. They also act as references to the original value, by including an actor to which the client can send messages to modify the value in the debuggee.
A grip has one of the following forms:
```
value
```
where value is a string, a number, or a boolean value. For these types of values, the grip is simply the JSON form of the value.
```
{ "type":"null" }
```
This represents the JavaScript `null` value. (The protocol does not represent JavaScript `null` simply by the JSON `null`, for the convenience of clients implemented in JavaScript: this representation allows such clients to use `typeof(grip) == "object"` to decide whether the grip is simple or not.)
```
{ "type":"undefined" }
```
This represents the JavaScript `undefined` value. (`undefined` has no direct representation in JSON.)
```
{ "type":"Infinity" }
```
This represents the JavaScript `Infinity` value. (`Infinity` has no direct representation in JSON.)
```
{ "type":"-Infinity" }
```
This represents the JavaScript `-Infinity` value. (`-Infinity` has no direct representation in JSON.)
```
{ "type":"NaN" }
```
This represents the JavaScript `NaN` value. (`NaN` has no direct representation in JSON.)
```
{ "type":"-0" }
```
This represents the JavaScript `-0` value. (`-0` stringifies to JSON as 0.)
```
{ "type":"object", "class":className, "actor":actor }
```
This represents a JavaScript object whose class is `className`. (Arrays and functions are treated as objects for the sake of forming grips.) Actor can be consulted for the object's contents, as explained below.
If the class is "Function", the grip may have additional properties:
```
{ "type":"object", "class":"Function", "actor":actor,
"name":name, "displayName":displayName,
"userDisplayName":userDisplayName,
"url":url, "line":line, "column":column }
```
These additional properties are:
***Name***
The function's name (as given in the source code, following the `function` keyword), as a string. If the function is anonymous, the `name` property is omitted.
***displayName***
A name the system has inferred for the function (say, `"Foo.method"`). If the function has a given name (appearing in the grip as the `"name"` property), or if the system was unable to infer a suitable name for it, the `displayName` property is omitted.
***userDisplayName***
If the function object has a `"displayName"` value property whose value is a string, this is that property's value. (Many JavaScript development tools consult such properties, to give developers a way to provide their own meaningful names for functions.)
***url***
The URL of the function's source location (see [Source Locations](#source-locations));
***line***
The line number of the function's source location (see [Source Locations](#source-locations));
***column***
The column number of the function's source location (see [Source Locations](#source-locations));
```
{ "type":"longString", "initial":initial, "length":length, "actor":actor }
```
This represents a very long string, where "very long" is defined at the server's discretion. `Initial` is some initial portion of the string, `length` is the string's full length, and actor can be consulted for the rest of the string, as explained below.
For example, the following table shows some JavaScript expressions and the grips that would represent them in the protocol:
| JavaScript Expression | Grip |
|:--------------------------------------------------------:|:---------------------------------------------------------------------------------------------:|
| 42 | 42 |
| true | true |
| "nasu" | "nasu" |
| (void 0) | `{ "type":"undefined" }` |
| ({x:1}) | `{ "type":"object", "class":"Object", "actor":"24" }` |
| "Arms and the man I sing, who, *[much, much more text]*" | `{ "type":"longString", "initial":"Arms and the man I sing", "length":606647, "actor":"25" }` |
Garbage collection will never free objects visible to the client via the protocol. Thus, actors representing JavaScript objects are effectively garbage collection roots.
#### Objects
While a thread is paused, the client can send requests to the actors appearing in object grips to examine the objects they represent in more detail.
##### Property Descriptors
Protocol requests that describe objects' properties to the client often use **descriptors**, JSON values modeled after ECMAScript 5's property descriptors, to describe individual properties.
A descriptor has the form:
```
{ "enumerable":<enumerable>, "configurable":<configurable>, ... }
```
where *enumerable* and *configurable* are boolean values indicating whether the property is enumerable and configurable, and additional properties are present depending on what sort of property it is.
A descriptor for a data property has the form:
```
{ "enumerable":<enumerable>, "configurable":<configurable>,
"value":<value>, "writeable":<writeable> }
```
where *value* is a grip on the property's value, and *writeable* is a boolean value indicating whether the property is writeable.
A descriptor for an accessor property has the form:
```
{ "enumerable":<enumerable>, "configurable":<configurable>,
"get":<getter>, "set":<setter> }
```
where *getter* and *setter* are grips on the property's getter and setter functions. These may be `{ "type":"undefined" }` if the property lacks the given accessor function.
A **safe getter value descriptor** provides a value that an inherited accessor returned when applied to an instance. (See [Finding An Object's Prototype And Properties](#finding-an-object-s-prototype-and-properties) for an explanation of why and when such descriptors are used.) Such a descriptor has the form:
```
{ "getterValue": <value>, "getterPrototypeLevel": <level>,
"enumerable":<enumerable>, "writable":<writable> }
```
where *value* is a grip on the value the getter returned, *level* is the number of steps up the object's prototype chain one must take to find the object on which the getter appears as an own property. If the getter appears directly on the object, *level* is zero. The *writable* property is true if the inherited accessor has a setter, and false otherwise.
For example, if the JavaScript program being debugged evaluates the expression:
```
({x:10, y:"kaiju", get a() { return 42; }})
```
then a grip on this value would have the form:
```
{ "type":"object", "class":"Object", "actor":<actor> }
```
and sending a ["prototypeAndProperties"](#finding-an-object-s-prototype-and-properties) request to *actor* would produce the following reply:
```
{ "from":<actor>, "prototype":{ "type":"object", "class":"Object", "actor":<objprotoActor> },
"ownProperties":{ "x":{ "enumerable":true, "configurable":true, "writeable":true, "value":10 },
"y":{ "enumerable":true, "configurable":true, "writeable":true, "value":"kaiju" },
"a":{ "enumerable":true, "configurable":true,
"get":{ "type":"object", "class":"Function", "actor":<getterActor> },
"set":{ "type":"undefined" }
}
}
}
```
Sending a ["prototypeAndProperties"](#finding-an-object-s-prototype-and-properties) request to an object actor referring to a DOM mouse event might produce the following reply:
```
{ "from":<mouseEventActor>, "prototype":{ "type":"object", "class":"MouseEvent", "actor":<mouseEventProtoActor> },
"ownProperties":{ }
"safeGetterValues":{ "screenX": { "getterValue": 1000, "getterPrototypeLevel": 1,
"enumerable": true, "writable": false },
"screenY": { "getterValue": 1000, "getterPrototypeLevel": 1,
"enumerable": true, "writable": false },
"clientX": { "getterValue": 800, "getterPrototypeLevel": 1,
"enumerable": true, "writable": false },
"clientY": { "getterValue": 800, "getterPrototypeLevel": 1,
"enumerable": true, "writable": false },
...
}
}
```
##### Finding An Object's Prototype And Properties
To examine an object's prototype and properties, a client can send the object's grip's actor a request of the form:
```
{ "to":<gripActor>, "type":"prototypeAndProperties" }
```
to which the grip actor replies:
```
{ "from":<gripActor>, "prototype":<prototype>, "ownProperties":<ownProperties> }
```
where *prototype* is a grip on the object's prototype (possibly `{ "type":"null" }`), and *ownProperties* has the form:
```
{ name:<descriptor>, ... }
```
with a *name*:<descriptor> pair for each of the object's own properties.
The web makes extensive use of inherited accessor properties; for example, the `clientX` and `clientY`> properties of a mouse click event are actually accessor properties which the event object inherits from its prototype chain. It can be very valuable to display such properties' values directly on the object (taking care to distinguish them from true "own" properties), if the server can determine that the getters can be called without side effects.
To this end, when possible, the server may provide safe getter value descriptors for an object, as described in [Property Descriptors](#property-descriptors) above, reporting the values that getter functions found on the object's prototype chain return when applied to that object. If the server chooses to provide any, the reply includes a `"safeGetterValues"` property of the form:
```
{ name:<descriptor>, ... }
```
with a *name*:<descriptor> pair for each safe getter the object inherits from its prototype chain, or that appears directly on the object. Each *descriptor* here is a safe getter value descriptor.
*TODO: What about objects with many properties?*
##### Finding an Object's Prototype
To find an object's prototype, a client can send the object's grip's actor a request of the form:
```
{ "to":<gripActor>, "type":"prototype" }
```
to which the grip actor replies:
```
{ "from":<gripActor>, "prototype":<prototype> }
```
where *prototype* is a grip on the object's prototype (possibly `{ "type":"null" }`).
##### Listing an Object's Own Properties' Names
To list an object's own properties' names, a client can send the object's grip's actor a request of the form:
```
{ "to":<gripActor>, "type":"ownPropertyNames" }
```
to which the grip actor replies:
```
{ "from":<gripActor>, "ownPropertyNames":[ <name>, ... ] }
```
where each *name* is a string naming an own property of the object.
##### Finding Descriptors For Single Properties
To obtain a descriptor for a particular property of an object, a client can send the object's grip's actor a request of the form:
```
{ "to":<gripActor>, "type":"property", "name":<name> }
```
to which the grip actor replies:
```
{ "from":<gripActor>, "descriptor":<descriptor> }
```
where *descriptor* is a descriptor for the own property of the object named *name*, or `null` if the object has no such own property.
A property descriptor has the form:
```
{ "configurable":<configurable>, "enumerable":<enumerable>, ... }
```
where *configurable* and *enumerable* are boolean values. *Configurable* is true if the property can be deleted or have its attributes changed. *Enumerable* is true if the property will be enumerated by a `for-in` enumeration.
Descriptors for value properties have the form:
```
{ "configurable":<configurable>, "enumerable":<enumerable>,
"writable":<writable>, "value":<value> }
```
where *writable* is `true` if the property's value can be written to; *value* is a grip on the property's value; and *configurable* and *enumerable* are as described above.
Descriptors for accessor properties have the form:
```
{ "configurable":<configurable>, "enumerable":<enumerable>,
"get":<get>, "set":<set> }
```
where *get* and *set* are grips on the property's getter and setter functions; either or both are omitted if the property lacks the given accessor function. *Configurable* and *enumerable* are as described above.
*TODO: assign to value property*
*TODO: special stuff for arrays*
*TODO: special stuff for functions*
*TODO: find function's source position*
*TODO: get function's named arguments, in order*
*TODO: descriptors for Harmony proxies*
##### Functions
If an object's class as given in the grip is `"Function"`, then the grip's actor responds to the messages given here.
```
{ "to":<functionGripActor>, "type":"parameterNames" }
```
This requests the names of the parameters of the function represented by *functionGripActor*. The reply has the form:
```
{ "from":<functionGripActor>, "parameterNames":[ <parameter>, ... ] }
```
where each *parameter* is the name of a formal parameter to the function as a string. If the function takes destructuring arguments, then *parameter* is a structure of JSON array and object forms matching the form of the destructuring arguments.
```
{ "to":<functionGripActor>, "type":"scope" }
```
Return the lexical environment over which the function has closed. The reply has the form:
```
{ "from":<functionGripActor>, "scope":<environment> }
```
where *environment* is a [lexical environment](#lexical-environments). Note that the server only returns environments of functions in a context being debugged; if the function's global scope is not the browsing context to which we are attached, the function grip actor sends an error reply of the form:
```
{ "from":<functionGripActor>, "error":"notDebuggee", "message":<message> }
```
where *message* is text explaining the problem.
```
{ "to":<functionGripActor>, "type":"decompile", "pretty":<pretty> }
```
Return JavaScript source code for a function equivalent to the one represented by *functionGripActor*. If the optional `pretty` parameter is present and *pretty* is `true`, then produce indented source code with line breaks. The reply has the form:
```
{ "from":<functionGripActor>, "decompiledCode":<code> }
```
where *code* is a string.
If *functionGripActor*'s referent is not a function, or is a function proxy, the actor responds to these requests with an error reply of the form:
```
{ "from":<functionGripActor>, "error":"objectNotFunction", message:<message> }
```
where *message* is a string containing any additional information that would be helpful to debugger developers.
#### Long Strings
The client can find the full contents of a long string by sending a request to the long string grip actor of the form:
```
{ "to":<gripActor>, "type":"substring", "start":<start>, "end":<end> }
```
where *start* and *end* are integers. This requests the substring starting at the *start*'th character, and ending before the *end*'th character. The actor replies as follows:
```
{ "from":<gripActor>, "substring":<string> }
```
where *string* is the requested portion of the string the actor represents. Values for *start* less than zero are treated as zero; values greater than the length of the string are treated as the length of the string. Values for *end* are treated similarly. If *end* is less than *start*, the two values are swapped. (This is meant to be the same behavior as JavaScript's `String.prototype.substring`.)
As with any other actor, the client may only send messages to a long string grip actor while it is alive: for [pause-lifetime grips](#grip-lifetimes), until the debuggee is resumed; or for [thread-lifetime grips](#grip-lifetimes), until the thread is detached from or exits. However, unlike object grip actors, the client may communicate with a long string grip actor at any time the actor is alive, regardless of whether the debuggee is paused. (Since strings are immutable values in JavaScript, the responses from a long string grip actor cannot depend on the actions of the debuggee.)
#### Grip Lifetimes
Most grips are **pause-lifetime** grips: they last only while the JavaScript thread is paused, and become invalid as soon as the debugger allows the thread to resume execution. (The actors in pause-lifetime grips are children of an actor that is closed when the thread resumes, or is detached from.) This arrangement allows the protocol to use grips freely in responses without requiring the client to remember and close them all.
However, in some cases the client may wish to retain a reference to an object or long string while the debuggee runs. For example, a panel displaying objects selected by the user must update its view of the objects each time the debuggee pauses. To carry this out, the client can promote a pause-lifetime grip to a **thread-lifetime** grip, which lasts until the thread is detached from or exits. Actors in thread-lifetime grips are children of the thread actor. When the client no longer needs a thread-lifetime grip, it can explicitly release it.
Both pause-lifetime and thread-lifetime grips are garbage collection roots.
To promote a pause-lifetime grip to a thread-lifetime grip, the client sends a packet of the form:
```
{ "to":<gripActor>, "type":"threadGrip" }
```
where *gripActor* is the actor from the existing pause-lifetime grip. The grip actor will reply:
```
{ "from":<gripActor>, "threadGrip":<threadGrip> }
```
where *threadGrip* is a new grip on the same object, but whose actor is parented by the thread actor, not the pause actor.
The client can release a thread-lifetime grip by sending the grip actor a request of the form:
```
{ "to":<gripActor>, "type":"release" }
```
The grip actor will reply, simply:
```
{ "from":<gripActor> }
```
This closes the grip actor. The `"release"` packet may only be sent to thread-lifetime grip actors; if a pause-lifetime grip actor receives a `"release"` packet, it sends an error reply of the form:
```
{ "from":<gripActor>, "error":"notReleasable", "message":<message> }
```
where each *gripActor* is the name of a child of *thread* that should be freed. The thread actor will reply, simply:
```
{ "from":<thread> }
```
Regardless of the lifetime of a grip, the client may only send messages to object grip actors while the thread to which they belong is paused; the client's interaction with mutable values cannot take place concurrently with the thread.
### Completion Values
Some packets describe the way a stack frame's execution completed using a **completion value**, which takes one of the following forms:
```
{ "return":<grip> }
```
This indicates that the frame completed normally, returning the value given by *grip*.
```
{ "throw":<grip> }
```
This indicates that the frame threw an exception; *grip* is the exception value thrown.
```
{ "terminated":true }
```
This indicates that the frame's execution was terminated, as by a "slow script" dialog box or running out of memory.
### Source Locations
Many packets refer to particular locations in source code: breakpoint requests specify where the breakpoint should be set; stack frames show the current point of execution; and so on.
Descriptions of source code locations (written as *location* in packet descriptions) can take one of the following forms:
```
{ "url":<url>, "line":<line>, "column":<column> }
```
This refers to line *line*, column *column* of the source code loaded from *url*. Line and column numbers start with 1. If *column* or *line* are omitted, they default to 1.
```
{ "eval":<location>, "id":<id>, "line":<line>, "column":<column> }
```
This refers to line *line*, column *column* of the source code passed to the call to eval at *location*. To distinguish the different texts passed to eval, each is assigned a unique integer, *id*.
```
{ "function":<location>, "id":<id>, "line":<line>, "column":<column> }
```
This refers to line *line*, column *column* of the source code passed to the call to the `Function` constructor at *location*. To distinguish the different texts passed to the `Function` constructor, each is assigned a unique integer, *id*.
As indicated, locations can be nested. A location like this one:
```
{ "eval":{ "eval":{ "url":"file:///home/example/sample.js", "line":20 }
"id":300, "line":30 }
"id":400, "line":40 }
```
refers to line 40 of the code passed to the call to eval occurring on line 30 of the code passed to the call to eval on line 20 of `file:///home/example/sample.js`.
## The Root Actor
When the connection to the server is opened, the root actor opens the conversation with the following packet:
```
{ "from":"root", "applicationType":<appType>, "traits":<traits>, ...}
```
The root actor's name is always `"root"`. *appType* is a string indicating what sort of program the server represents. There may be more properties present, depending on *appType*.
*traits* is an object describing protocol variants this server supports that are not convenient for the client to detect otherwise. The property names present indicate what traits the server has; the properties' values depend on their names. If *traits* would have no properties, the `"traits"` property of the packet may be omitted altogether. This version of the protocol defines no traits, so if the `"traits"` property is present at all, its value must be an object with no properties, `{}`.
For web browsers, the introductory packet should have the following form:
```
{ "from":"root", "applicationType":"browser", "traits":<traits> }
```
### Listing Browser Tabs
To get a list of the tabs currently present in a browser, a client sends the root actor a request of the form:
```
{ "to":"root", "type":"listTabs" }
```
The root actor replies:
```
{ "from":"root", "tabs":[<tab>, ...], "selected":<selected> }
```
where each *tab* describes a single open tab, and *selected* is the index in the array of tabs of the currently selected tab. This form may have other properties describing other global actors; for one example, see [Chrome Debugging](#chrome-debugging).
Each *tab* has the form:
```
{ "actor":<targetActor>, "title":<title>, "url":<URL> }
```
where *targetActor* is the name of an actor representing the tab, and *title* and *URL* are the title and URL of the web page currently visible in that tab. This form may have other properties describing other tab-specific actors.
To attach to a *targetActor*, a client sends a message of the form:
```
{ "to":<targetActor>, "type":"attach" }
```
The target actor replies:
```
{ "from":<targetActor>, "threadActor":<tabThreadActor> }
```
where *tabThreadActor* is the name of a thread-like actor representing the tab's current content. If the user navigates the tab, *tabThreadActor* switches to the new content; we do not create a separate thread-like actor each page the tab visits.
If the user closes the tab before the client attaches to it, *targetActor* replies:
```
{ "from":<targetActor>, "error":"exited" }
```
When the client is no longer interested in interacting with the tab, the client can request:
```
{ "to":<targetActor>, "type":"detach" }
```
The *targetActor* replies:
```
{ "from":<targetActor>, "type":"detached" }
```
If the client was not already attached to *targetActor*, *targetActor* sends an error reply of the form:
```
{ "from":<targetActor>, "error":"wrongState" }
```
While the client is attached, *targetActor* sends notifications to the client whenever the user navigates the tab to a new page. When navigation begins, *targetActor* sends a packet of the form:
```
{ "from":<targetActor>, "type":"tabNavigated", "state":"start",
"url":<newURL> }
```
This indicates that the tab has begun navigating to *newURL*; JavaScript execution in the tab's prior page is suspended. When navigation is complete, *targetActor* sends a packet of the form:
```
{ "from":<targetActor>, "type":"tabNavigated", "state":"stop",
"url":<newURL>, "title":<newTitle> }
```
where *newURL* and *newTitle* are the URL and title of the page the tab is now showing. The *tabThreadActor* given in the response to the original `"attach"` packet is now debugging the new page's code.
### Chrome Debugging
If the server supports debugging chrome code, the root actor's reply to a `"listTabs"` request includes a property named `"chromeDebugger"`, whose value is the name of a thread-like actor to which the client can attach to debug chrome code.
## Interacting with Thread-Like Actors
Actors representing independent threads of JavaScript execution, like browsing contexts and web workers, are collectively known as "threads". Interactions with actors representing threads follow a more complicated communication pattern.
A thread is always in one of the following states:
* **Detached**: the thread is running freely, and not presently interacting with the debugger. Detached threads run, encounter errors, and exit without exchanging any sort of messages with the debugger. A debugger can attach to a thread, putting it in the **Paused** state. Or, a detached thread may exit on its own, entering the **Exited** state.
* **Running**: the thread is running under the debugger's observation, executing JavaScript code or possibly blocked waiting for input. It will report exceptions, breakpoint hits, watchpoint hits, and other interesting events to the client, and enter the **Paused** state. The debugger can also interrupt a running thread; this elicits a response and puts the thread in the **Paused** state. A running thread may also exit, entering the **Exited** state.
* **Paused**: the thread has reported a pause to the client and is awaiting further instructions. In this state, a thread can accept requests and send replies. If the client asks the thread to continue or step, it returns to the **Running** state. If the client detaches from the thread, it returns to the **Detached** state.
* **Exited**: the thread has ceased execution, and will disappear. The resources of the underlying thread may have been freed; this state merely indicates that the actor's name is not yet available for reuse. When the actor receives a "release" packet, the name may be reused.
These interactions are meant to have certain properties:
* At no point may either client or server send an unbounded number of packets without receiving a packet from its counterpart. This avoids deadlock without requiring either side to buffer an arbitrary number of packets per actor.
* In states where a transition can be initiated by either the debugger or the thread, it is always clear to the debugger which state the thread actually entered, and for what reason.<br>For example, if the debugger interrupts a running thread, it cannot be sure whether the thread stopped because of the interruption, paused of its own accord (to report a watchpoint hit, say), or exited. However, the next packet the debugger receives will either be "paused", or "exited", resolving the ambiguity.<br>Similarly, when the debugger attaches to a thread, it cannot be sure whether it has succeeded in attaching to the thread, or whether the thread exited before the "attach" packet arrived. However, in either case the debugger can expect a disambiguating response: if the attach succeeded, it receives an "attached" packet; and in the second case, it receives an "exit" packet.<br>To support this property, the thread ignores certain debugger packets in some states (the "interrupt" packet in the **Paused** and **Exited** states, for example). These cases all handle situations where the ignored packet was preempted by some thread action. |
