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` 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
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
> 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
> 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 mailing list