Remote Debugging Protocol: Difference between revisions

m
→‎The Root Actor: No unquoted identifiers in JSON.
m (→‎The Root Actor: No unquoted identifiers in JSON.)
Line 47: Line 47:
When the connection to the server is opened, the root actor opens the conversation with the following packet:
When the connection to the server is opened, the root actor opens the conversation with the following packet:


   { from:0, application-type:<i>app-type</i>, traits:<i>traits</i>, ...}
   { "from":0, "application-type":<i>app-type</i>, "traits":<i>traits</i>, ...}


The root actor's name is always zero. <i>app-type</i> is a JSON string indicating what sort of program the server represents. There may be more properties present, depending on <i>app-type</i>.
The root actor's name is always zero. <i>app-type</i> is a JSON string indicating what sort of program the server represents. There may be more properties present, depending on <i>app-type</i>.
Line 55: Line 55:
For web browsers, the introductory packet should have the following form:
For web browsers, the introductory packet should have the following form:


   { from:0, application-type:"browser", traits:<i>traits</i> }
   { "from":0, "application-type":"browser", "traits":<i>traits</i> }


== Listing Top-Level Browsing Contexts ==
== Listing Top-Level Browsing Contexts ==
Line 61: Line 61:
To get a list of the top-level browsing contexts present in a browser, a client should send a packet like the following to the root actor:
To get a list of the top-level browsing contexts present in a browser, a client should send a packet like the following to the root actor:


   { to:0, type:"list-contexts" }
   { "to":0, "type":"list-contexts" }


The response should have the form:
The response should have the form:


   { from:0, contexts: [<i>CONTEXT</i>...] }
   { "from":0, "contexts":[<i>CONTEXT</i>...] }


The 'contexts' property is a list with one element for each top-level browsing context present in the browser. Each <i>CONTEXT</i> has the following form:
The 'contexts' property is a list with one element for each top-level browsing context present in the browser. Each <i>CONTEXT</i> has the following form:


   { actor:<i>ACTOR</i>, title:<i>TITLE</i>, url:<i>URL</i> }
   { "actor":<i>ACTOR</i>, "title":<i>TITLE</i>, "url":<i>URL</i> }


<i>ACTOR</i> is the actor representing that top-level browsing context; <i>TITLE</i> is the context's document's title, and <i>URL</i> is the context's document's URL.
<i>ACTOR</i> is the actor representing that top-level browsing context; <i>TITLE</i> is the context's document's title, and <i>URL</i> is the context's document's URL.
Line 79: Line 79:
For example, upon connection to a web browser visiting two pages at example.com, the root actor's introductory packet might look like this:
For example, upon connection to a web browser visiting two pages at example.com, the root actor's introductory packet might look like this:


   { from:0, application-type:"browser", traits:{}
   { "from":0, "application-type":"browser",
     contexts: [ { actor:1, title:"Fruits",
     "contexts": [ { "actor":1, "title":"Fruits",
                  url:"http://www.example.com/fruits/"},
                    "url":"http://www.example.com/fruits/"},
                { actor:2, title:"Bats",
                  { "actor":2, "title":"Bats",
                  url:"http://www.example.com/bats/"}]}
                    "url":"http://www.example.com/bats/"}]}


<i>(The point here is to give the debugger enough information to select which context it would like to debug without having to do too many round trips. Round trips are bad for UI responsiveness, but large packets are probably not a problem, so whatever would help to add, we should add.)</i>
<i>(The point here is to give the debugger enough information to select which context it would like to debug without having to do too many round trips. Round trips are bad for UI responsiveness, but large packets are probably not a problem, so whatever would help to add, we should add.)</i>
Confirmed users
496

edits