Changes

== Listing Top-Level Browsing Contexts Browser Tabs ==

To get a list of the top-level browsing contexts (tabs) currently present in a browser, a client should send sends the root actor a request like the following to of the root actorform:

{ "to":"root", "type":"listContextslistTabs" }

The reply should have the formroot actor replies:

{ "from":"root", "contextstabs":[<i>contexttab</i>, ...], "selected":<i>indexselected</i> }

The where each <tti>contextstab</tti> property's value is an array with one element for each top-level browsing context present in the browserdescribes a single open tab, and <i>indexselected</i> is the index within that list in the array of tabs of the browsing context the user is currently interacting withselected tab. Each <i>context</i> has the following This form:may have other properties describing other global actors; for one example, see [[#Chrome_Debugging|Chrome Debugging]].

{ "actor":<i>actor</i>, "title":Each <i>titletab</i>, "url"has the form:<i>url</i> }

{ "actor":<i>actortabActor</i> is the actor representing that top-level browsing context; , "title":<i>title</i> is the context's document's title, and "url":<i>urlURL</i> is the context's document's URL.}

Clients should send "listContexts" requests only to root actors where <i>tabActor</i> is the name of an actor representing the tab, and <i>title</i> and <i>URL</i> are the title and URL of the web page currently visible in that tab. This form may have identified themselves as browsersother properties describing other tab-specific actors.

Actor names given in a list-contexts reply are children of the root actor. They remain valid at least until the next list-contexts request is received. If the client attaches To attach to a context actor<i>tabActor</i>, its name is valid at least until the client detaches from the context and receives a "detached" packet from the context, or until the client sends a "release" packet to message of the context. (These packets are described in detail in [[#Interacting_with_Thread-Like_Actors|Interacting with Thread-Like Actors]].)form:

For example, upon connection { "to a web browser visiting two pages at example.com":<i>tabActor</i>, the root actor's introductory packet might look like this"type":"attach" }

{ "from":"root", "applicationType":"browser", "contexts":[ { "The tab actor":"context1", "title":"Fruits", "url":"http://www.example.com/fruits/" }, { "actor":"context2", "title":"Bats", "url":"httpreplies://www.example.com/bats/" }]}

{ "from":<i>(This may not be the right information to provide in these packets; suggestions very welcome. 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 responsivenesstabActor</i>, but large packets are probably not a problem"type":"tabAttached", so whatever would help to add, we should add.)"threadActor":<i>tabThreadActor</i>}

where <i>There are othertabThreadActor</i> is the name of a thread-like actor representing the tab's current content. If the user navigates the tab, more important ways this may be wrong<i>tabThreadActor</i> switches to the new content; we do not create a separate thread-headedlike actor each page the tab visits. In traditional Firefox If the user closes the tab before the client attaches to it, <i>tabActor</i> replies:  { "from":<i>tabActor</i>, there "type":"exited" } When the client is only one thread for all chrome and content. One no longer interested in interacting with the tab, the client can't attach request:  { "to":<i>tabActor</i>, "type":"detach" } The <i>tabActor</i> replies:  { "from":<i>tabActor</i>, "type":"detached" } If the client was not already attached to <i>tabActor</i>, <i>tabActor</i> sends an error reply of the form:  { "from":<i>tabActor</i>, "error":"wrongState" } While the client is attached, <i>tabActor</i> sends unsolicited notifications to different tabs and then continue them independently; they're all sharing the same stackclient whenever the user navigates the tab to a new page. When navigation begins, <i>tabActor</i> sends a packet of the form:  { "from":<i>tabActor</i>, "type":"tabNavigated", "state":"start", "url":<i>newURL</i> } This will still be true indicates that the tab has begun navigating to some extent even when we have out-<i>newURL</i>; JavaScript execution in the tab's prior page is suspended. When navigation is complete, <i>tabActor</i> sends a packet of-process contentthe form:  { "from":<i>tabActor</i>, "type":"tabNavigated", "state":"stop", "url":<i>newURL</i>, because you'll necessarily have groups "title":<i>newTitle</i> } where <i>newURL</i> and <i>newTitle</i> are the URL and title of tabs sharing a threadthe page the tab is now showing. The thread actor interactions described below seem like <i>tabThreadActor</i> given in the right way response to interact with the original <code>"attach"</code> request is now debugging the new page's code. If the user closes a threadtab to which the client is attached, its <i>tabActor</i> sends an unsolicited packet of the form:  { "from":<i>tabActor</i>, "type":"tabDetached" } The client is now detached from the tab. == Chrome Debugging == If the server supports debugging chrome code, but we need the root actor's reply to explain how we select some parts a <code>"listTabs"</code> request includes a property named <code>"chromeDebugger"</code>, whose value is the name of a thread-like actor to which the browser client can attach to debug and others to ignorechrome code.</i>