---------- 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

Reply via email to