Introduce a browsing context group

[annevk]

As far as I can tell the "unit of related browsing contexts" idea is broken. E.g., if a top-level opens two auxiliary browsing contexts, and all contain same-origin documents, and then the top-level closes itself or gets closed, the two auxiliary browsing contexts might not have a reference to each other's WindowProxy, but definitely need to remain tied as their documents need to be in the same agent cluster. However, per the current definition they'd suddenly no longer be in the same unit.

Therefore, I think we need a browsing context group, which holds a set of top-level/auxiliary browsing contexts and also a map of site to agent clusters.

cc @mystor

(Note: "units of related similar-origin browsing contexts" is also broken, as a browsing context can hold many origins.)

[mystor]

I believe that membership into a Browsing Context Group shouldn't be too complex (although there are certainly edge cases):

1. When a Nested Browsing Context is created, it joins the Browsing Context Group of its parent Browsing Context
2. When an Auxiliary Browsing Context is created, it joins the Browsing Context Group of its opener Browsing Context, unless it was created by a window.open or targeted document load which is, explicitly or implicitly, marked as noopener.

One reason why I haven't tried to do this before is the noopener case, and how there may be some ugly edge cases around maintaining some concept of connectedness (for the purposes of e.g. popup blocking), while not causing noopener documents to join the same Browsing Context Group.

In terms of Unit of Related Similar-Origin Browsing Contexts, I'm imagining it can be defined as "Globals in a Window Agent", where two same-site documents must share an event loop (and thus a Window Agent), if they are in the same Browsing Context Group.

[domenic]

I hope we can reuse the same terms and fix their definitions, instead of creating two parallel ones.

Separately, can you spell out why they need to remain in the same agent cluster? I can see how that's the case if they're already sharing memory, but if they haven't done so yet, then it seems like a valid and unobservable thing to do to move them to separate processes and prohibit further sharing.

[mystor]

@domenic

I hope we can reuse the same terms and fix their definitions, instead of creating two parallel ones.

I think the goal here is to kill the old terms entirely, not create two parallel terms. The old names weren't exactly amazing, so switching to a more descriptive name seems like a generally good thing.

I also don't want to have two parallel similar-but-not-identical definitions in the spec.

Separately, can you spell out why they need to remain in the same agent cluster? I can see how that's the case if they're already sharing memory, but if they haven't done so yet, then it seems like a valid and unobservable thing to do to move them to separate processes and prohibit further sharing.

I ideally don't want the spec to require that browser authors keep track of which globals have references to which WindowProxy objects in order to make decisions about Browsing Context Group or Window Agent membership. Window Agent membership is currently observable using BroadcastChannel (e.g. #3759), so it would be good to have a well defined mechanism for defining what it implies in the spec.

To my knowledge no browser can move an executing live JS environment between processes, and doing so would probably be prohibitively expensive. If that is at some point possible, then it would theoretically be possible for document.domain to "synchronously" cause the current document to flip processes, making a lot of the concerns here less relevant (as you can just use origin-domain for isolation directly).

Window Agent membership is specific to a single global, so during navigations, it is certainly possible to switch processes. The concern would be that if we say have:

+---------------+     +--------+     +---------------+
| a.example.com | <-> | ~dead~ | <-> | b.example.com |
+---------------+     +--------+     +---------------+

I'm guessing you want to be able to have loaded b.example.com in a different Browsing Context Group (and thus a different Window Agent) than a.example.com?

My worry around that is potentially requiring tracking the WindowProxy references created to every related window for each global in order to be spec compliant (e.g. WRT BroadcastChannel behaviour). It is unfortunately possible that while ~dead~ was alive, references were passed around, and these two contexts can access each other now :-/.

[domenic]

Thanks for explaining. The WindowProxy reference issue probably indeed makes it not worth allowing the extra flexibility.

Back to the naming issue, I don't think it's worthwhile creating all that spec and ecosystem churn just to bugfix a definition. If we did that every time we fixed a bug in something's definition, nobody would be able to keep track of anything in the HTML spec. Keep in mind that these terms are used in more places than just the HTML spec, so we'd need to update all those as well.

[annevk]

I'm glad we agree on maximizing the opportunities for parallelization. And yeah, unless BroadcastChannel doesn't support SharedArrayBuffer I don't see additional opportunities here (this does again make me think that BroadcastChannel being able to do that isn't the best).

As for the data structure, I was thinking a browsing context group would hold a set of top-level/auxiliary browsing contexts (with at most one top-level), and not all descendants of those as well (as unit does). It's not clear to me the latter is a useful data structure.

The other thing is that the existing uses of the term "unit of related similar-origin browsing contexts" need to say agent instead, so keeping that term around, but making it mean something entirely different, seems bad to me. It seems much better to start fresh, to make this mistake clear.

[annevk]

To elaborate, I think what we want is a set of browsing context trees. A set of browsing contexts with no hierarchy isn't particularly useful, as far as I can tell. And the main terminology used outside the HTML standard is the "similar-origin" one, where "similar-origin window agent" is really what is meant. I've been meaning to update DOM to use that instead, I guess I can start there.

[domenic]

As for the data structure, I was thinking a browsing context group would hold a set of top-level/auxiliary browsing contexts (with at most one top-level), and not all descendants of those as well (as unit does). It's not clear to me the latter is a useful data structure.

To elaborate, I think what we want is a set of browsing context trees.

So far we have many places in the spec where UORSOBCs is useful, and I haven't seen any where either of your two new concepts would be helpful. Could you elaborate? In general I would prefer not to introduce new concepts if we can avoid them.

The other thing is that the existing uses of the term "unit of related similar-origin browsing contexts" need to say agent instead

Why? (Assuming the appropriate bugfix.)

so keeping that term around, but making it mean something entirely different, seems bad to me.

Can you explain why this bugfix makes the term "mean something entirely different", in your estimation?

It seems much better to start fresh, to make this mistake clear.

I think you underestimate the cost of starting fresh here, and overestimate how big of a mistake this is. Before shared memory, it was unobservable; we just forgot to patch the definition a bit when we introduced shared memory.

And the main terminology used outside the HTML standard is the "similar-origin" one, where "similar-origin window agent" is really what is meant.

Why is that the case?

[annevk]

A browsing context holds a sequence of documents. It therefore logically spans agent clusters and event loops. Therefore having a concept such as "similar-origin" doesn't make sense for a browsing context, since it can have multiple origins at the same time.

[domenic]

A browsing context has a distinguished active document.

[annevk]

Sure, but it's not only active documents that matter. And this makes it something that changes over time, rather than something you can allocate.

[domenic]

Only active documents matter in the definition of URSOBCs.

I think it's much nicer to have a definition that's always right, than one that you have to manually add and remove things from. I don't think moving toward a world of manually maintaining the contents of a collection is an improvement to the spec; I think it would be a regression.

[annevk]

I don't think that's true, since inactive documents also belong to the event loop, which is why this was always wrong and not at all how things are implemented.

[annevk]

And also, if we want to generalize language used for shared and service workers, having a totally alien concept to manage the same thing for documents is rather weird.

I'm a little surprised anyone would defend this setup.

[domenic]

I don't think that's true, since inactive documents also belong to the event loop, which is why this was always wrong and not at all how things are implemented.

Hmm, you may be right about that. Could you write up an example where we have an "orphan" inactive document that doesn't get an event loop per the current definition? I tried for a bit but wasn't able to create one.

I'm a little surprised anyone would defend this setup.

Similarly, I'm surprised anyone would seek to change it so drastically.

[annevk]

I want to change it because the current setup isn't at all ready for the kind of cross-process design we need.

I mean, if you simply remove a same-/cross-origin <iframe>, to what event loop does its document belong? Which "unit of related similar-origin browsing contexts"?

[domenic]

I want to change it because the current setup isn't at all ready for the kind of cross-process design we need.

I believe it has a bug, as this OP points out. I think we can fix that bug and then it will work great with the cross-process design we need.

I mean, if you simply remove a same-/cross-origin <iframe>, to what event loop does its document belong? Which "unit of related similar-origin browsing contexts"?

I'll try to make your example more concrete. We have 1 top-level BC with one iframe child BC. Both before and after the removal, they have a single active document, per https://html.spec.whatwg.org/#active-document. You have two scenarios, one same origin and one cross-origin.

Per https://html.spec.whatwg.org/#groupings-of-browsing-contexts they are directly reachable browsing contexts and are as such in the same unit of related browsing contexts. In the same-origin case, they can be same-origin-domain with each other, and so are in the same URSOBC. In the cross-origin case, assuming different eTLD+1s they can't, and so are in different URSOBCs. In the cross-origin case with the same eTLD+1s they can, and so are in the same URSOBC.

Does this help? Maybe we should add examples to the spec for cases like this?

[annevk]

How are they in the same URSOBC if the iframe is removed? How is it even in the same unit?

[domenic]

Why wouldn't they? For example, you can still share memory with JS that runs in that page; you can still synchronously access properties of that global... The definitions bear it out, and they match implementations.

[annevk]

Because the browsing context in the iframe no longer has a parent browsing context it's no longer in the same unit per the definition of unit of related browsing contexts.

[domenic]

Dang, you're right! Thanks for walking me through it!

Given an example like this, the only way to salvage a "simple" definition (in the sense of whatwg/dom#717 (comment)) would be to make it temporal anyway. E.g. change the bullet from "all the browsing context's child browsing contexts" to "all the browsing contexts that at some point were child browsing contexts of browsing context". But that's just a kind of awkward way of doing the explicit addition/removal you are advocating for. (Albeit a bit less error-prone, as it avoids issues where you can add but forget to remove, or similar.)

So, thank you, I'm cautiously on-board with changing to explicit management of realms.

Apart from that though, I hope you can work on an overview of the new paradigm you're shooting for, before we accept any piecemeal changes like #4204. In particular I'd like to ensure we don't create new concepts that are only slight variations on old ones (e.g. browsing context group/set of browsing context trees), and I'd like to preserve existing concepts as much as possible, just with different layering so they're not broken.

[rniwa]

I'd prefer a complete different set of names here because the current setup is way too confusing, and there are many subtle details that are going to change so that it's obvious when other specifications and implementation comments that refer to the old concepts. Subtle semantic change in this area is going to be really painful to follow up on.

[annevk]

After some IRC discussion I created this overview for the "new paradigm". I hope that we can work towards this in mostly incremental steps, as doing it all at once seems rather prohibitive, though also never in a way that leaves things in a broken state (even though things are in a broken state), as per our standard practice.

Main changes to the current model

A user agent:

• Holds a set of browsing context groups.
• Holds a shared worker map of origin to agent clusters.
• Holds a service worker map of origin to agent clusters.

(The maps for workers can be defined in parallel, later, or perhaps even abstractly. I don't think we need to worry about those too much for now as the existing agent cluster definition isn't too broken for them.)

A browsing context group:

• Holds a map of similar-origin window keys to agent clusters. A similar-origin window key is either (scheme, domain's registrable domain) or ("appropriate Spectre headers set", origin). (The second key is TBD, see Restricting cross-origin WindowProxy access (Cross-Origin-Opener-Policy) #3740 and Making postMessage() work for SharedArrayBuffer (Cross-Origin-Embedder-Policy) #4175.)
• Holds a set of top-level browsing contexts, with the constrain that there can be at most one non-auxiliary browsing context. New non-auxiliary browsing contexts (e.g., via rel=noopener and soon target=_blank) result in a new browsing context group.
• Is the scope for any name-based targating. (The actual lookup algorithm for names is still TBD, see Disowning owner should perhaps affect link targeting #313.)

Notes

• When creating a new browsing context group, we'll always need a top-level browsing context to start with, and that'll always need a new agent cluster.
• Whenever we need a new agent cluster, we'll also need a new similar-origin window agent, and a global and document. Note that each agent cluster in this browsing context group context will always have exactly one similar-origin window agent.
• Navigation will either result in a new global within the current agent/agent cluster or a new agent cluster.
• Additional agents in the agent cluster for this browsing context group context will all be dedicated worker or worklet agents, if any.
• A top-level browsing context is effectively the root of a tree of browsing contexts. Formalizing this in terms of https://dom.spec.whatwg.org/#concept-tree would make sense to me, but we have to be cautious somewhat as traversing this tree improperly leads to security issues. It's probably best to not make changes here for now and consider this separately.
• It's unclear how much the auxiliary browsing context distinction (i.e., top-level browsing contexts with the auxiliary bit set) needs to stick around given a browsing context group, but it's probably useful to tell what was a "popup" for certain things.