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.)
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!
The text was updated successfully, but these errors were encountered:
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:
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