I asked on #content about the WHATWG definition of a unit of related
similar-origin browsing contexts (UoRSOBC). I learned that, if you have an
iframe structure like this:
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, and the
grandchild can say `window.top` or `window.parent.parent`. There's a
special carve-out for certain properties that permits the grandparent and
child to access those properties on the parent, even though it's
cross-origin.
So the grandparent and child can call each others' functions, access each
others' objects, and so on. In Servo, this means that the grandparent and
child should share a ScriptThread.
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.
On Mon, Sep 19, 2016 at 10:07 AM, Eddy Bruel <ejpbr...@mozilla.com> wrote:
> ---------- Forwarded message ----------
> From: Eddy Bruel <ejpbr...@mozilla.com>
> Date: Mon, Sep 19, 2016 at 5:45 PM
> Subject: Maintaining a list of debugging targets in the debugger.
> To: Jim Blandy <j...@mozilla.com>, se...@mozilla.com
> Cc: Patrick Brosset <pbros...@mozilla.com>
>
>
> 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
> <https://html.spec.whatwg.org/multipage/browsers.html#unit-
> of-related-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 future be
> same-origin.”. I am not sure if this implies that two browsing contexts
> that are not part of the same unit of related SOB contexts can share a
> script thread. However, if that’s the case, then routing to the correct
> script thread it’s not going to be enough: we also need to target
> particular globals within that script thread.
> _______________________________________________
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
