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