Re: [dev-servo] Fwd: Maintaining a list of debugging targets in the debugger.

[Boris Zbarsky]

On 9/19/16 6:49 PM, Jim Blandy wrote:

   grandparent (origin O)
   parent (origin P, P != O)
   child (origin O, same as grandparent)

then the grandparent and the child are in the same UoRSOBC. The grandparent
can say `frame.contentWindow.frames[0]` to get its grandchild


frame.contentWindow should return null in this case.

But the grandparent can do window[0][0] (aka window.frames[0].frames[0]) 
to get the grandchild.


-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Fwd: Maintaining a list of debugging targets in the debugger.

[Jim Blandy]

On Mon, Sep 19, 2016 at 10:49 AM, Jim Blandy  wrote:

> However! It turns out that Servo doesn't implement this at all right now.
> At present, the above arrangement would create three ScriptThreads, and
> `frame.contentWindow == null` in the cross-origin case.
>

In case it wasn't clear: this is something that Servo knows it will need to
change to become compatible with the web.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Fwd: Maintaining a list of debugging targets in the debugger.

[Eddy Bruel]

-- Forwarded message --
From: Eddy Bruel 
Date: Mon, Sep 19, 2016 at 5:45 PM
Subject: Maintaining a list of debugging targets in the debugger.
To: Jim Blandy , se...@mozilla.com
Cc: Patrick Brosset 


Over the past few days, I've tried to come up with a way to maintain a list
of debugging targets in the debugger server, and how to route messages to
an individual debugging target. This has turned out to be rather
non-trivial, particularly because the notion of what a constitutes
debugging target is complex, and can change over time.

Below you will find an overview of what I've learned so far, partially to
force myself to order my own thoughts, partially to ask for your feedback
on the problem:

The unit of debugging should be a *unit of related similar-origin browsing
contexts
.*

A unit of related SOB contexts forms a tree of browsing contexts. The root
of this tree is either a tab, a worker, or a cross-origin iframe.

If a browsing context has one or more similar-origin children, these are
part of the same unit of related SOB contexts. For instance, if a tab has
one or more similar-origin iframes, both the tab and the iframes are part
of the same unit of related SOB contexts. Similarly, if one of these
iframes has one or more similar-origin sub-iframes, these too are part of
the same unit of related SOB contexts.

If a browsing context has one or more cross-origin children, these form
their own unit of related SOB contexts, with the child at the root. For
instance, if a tab has a cross-origin iframe, the iframe forms the root of
a separate unit of related SOB contexts. Similarly, if this cross-origin
iframe has one or more similar-origin sub-iframes, these too are part of
the same unit of related SOB contexts.

Navigation can cause a browsing context to move to a different unit of
related SOB contexts: for instance, if a same-origin iframe navigates to a
cross-origin URL, it will become the root of a separate unit of related SOB
contexts. Conversely, if a cross-origin iframe navigates to a same-origin
URL, it becomes part of an existing unit of related SOB contexts.


What does all this mean for the debugger server? First off, the debugger
server needs to maintain a list of units of related SOB contexts. Each of
these are valid debugging target for the debugger.

How do we maintain a list of units of related SOB contexts in the debugger?
Unfortunately, the constellation doesn’t know about units of related SOB
contexts; it only knows about frames. We need some way to group frames that
belong to the same unit of related SOB contexts. One way to accomplish this
could be to group frames that have the same effective top-level domain
together.

When a client connects to the debugger server, it does so using a URL that
determines a particular debugging target (i.e. a unit of related SOB
contexts). Because the debugger API needs to run in the same thread as the
debuggee, the debugger server cannot use the debugger API directly;
instead, it needs to request the script thread for the particular debugging
target to use the debugger API on its behalf.

Here is where things get complicated: so far, I assumed that each unit of
related SOB contexts has a unique script thread, and conversely, that each
script thread corresponds to a unique unit of related SOB contexts. If this
had been true, the debugger could send messages to the script thread for a
particular debugging target by sending a message to an arbitrary frame in
the corresponding unit of related SOB contexts, presumably using the
constellation to do the routing.

However, when a tab navigates, it is apparently assigned a new script
thread; therefore, even though a unit of related SOB contexts has a unique
script thread at any particular moment in time, the current script thread
can change over time. If we use the constellation to do the routing, it can
probably take care of this, but we need to make sure it doesn’t lead to any
nasty races (for instance, when a message is sent to the script thread by
the debugger in the middle of a navigation).

Furthermore, due to a bug in Servo, when a same-origin iframe navigates to
a same origin URL, it is assigned a new script thread. That means there is
no 1-1 relation ship between units of related SOB contexts and script
threads: there can be more than one script threads per unit of related SOB
contexts. This significantly complicates the routing. However, since this
is a problem that’s going to be fixed, we can probably ignore it for now
(simply always select the script thread of the topmost browsing context
within a particular unit of related SOB contexts).

More seriously, according to a conversation on irc I just had with
ajeffrey: “Making document.domain settable means we need to share script
threads among documents that may at some point in the