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.