User agents, session history, browsing contexts, and agent clusters

[annevk]

We need to figure out the proper relationship between these entities in order to diagram it (see #3863), but also to understand what we're building.

Here's my high-level sketch based on a conversation with @mystor a while back (mistakes mine):

---

A user agent holds shared/service worker agent cluster map, for agent clusters containing a shared worker agent or a service worker agent. (This is already shared understanding I think, but restating for clarity.)

A user agent holds a session set, consisting of zero or more sessions. (A session is roughly equivalent to what we call "session history" in HTML today, shortened here for brevity and distinction.)

A session consists of zero or more session entries. A session entry is effectively the state of a "session history entry", but also holds a reference to a top-level browsing context (as that can change within a session due to COOP).

A top-level browsing context is part of a browsing context group. (As defined today, except that a user agent no longer holds a browsing context group directly.)

A browsing context group holds an agent cluster map. (As sketched in #4361 and currently being formalized in #4617.) I would suggest we make this a weak map (not in the JavaScript sense) as managing the teardown of these agent clusters explicitly is tricky, e.g., it would make #4390 even more complicated as we'd have to handle the case of a "remote WindowProxy" trying to message an agent cluster that has disappeared explicitly as well, whereas otherwise we could pretend there's a smart cross-process GC that keeps it alive. And also, I don't think we really want to start reference count all the callers and such (or do a search for all usage whenever there's a change).

XXX: It's not clear that all worklets should have their own agent, e.g. audio worklets need to be part of an agent cluster that also holds a similar-origin window agent.

---

The key "changes" are that sessions are at the top as they need to manage transitions between top-level browsing contexts (what exactly ends up being observable here is up for debate, but there's ambition for "bfcache" at least). And since the scope of a session is a top-level browsing context, browsing context groups become a sideshow. And then also more clearly acknowledging that while a browsing context group keeps track of agent clusters, it's not responsible for collecting them. (This also helps with @dtapuska's scenario where each browsing context might get its own agent cluster. It'd be bad standard writing if we didn't allow those to be collected before all top-level browsing contexts in the browsing context group were closed.)

Thoughts on this appreciated!

[domenic]

This makes rough sense. What could help me understand it better is going through some semi-complex operations and how they move or change things, and thus allow "collection". E.g. you seem to have a mental model of how teardown works, but it's not obvious to me exactly which of the above concepts are involved.

Some operations in particular that would be interesting to see:

• Same-origin navigation
• Cross-site navigation
• Closing a normal browsing context
• Closing an auxiliary browsing context
• .remove()ing an iframe containing a nested browsing context
• Closing or navigating away all documents that are the owner of a given shared/service worker

[annevk]

I guess the remainder here is being addressed by #6315. Perhaps this can be closed. @jakearchibald?

[jakearchibald]

Let's wait until it's landable. I'm going to go through issues like this to check I actually spec'd what's required.