Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
annevk opened this issue Jul 17, 2019 · 3 comments · May be fixed by #6315
Open

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

annevk opened this issue Jul 17, 2019 · 3 comments · May be fixed by #6315
Labels
topic: agent topic: browsing context topic: history

Comments

@annevk
Copy link
Member

annevk commented Jul 17, 2019

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!

@annevk annevk added topic: history topic: browsing context topic: agent labels Jul 17, 2019
@domenic
Copy link
Member

domenic commented Jul 17, 2019

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
Copy link
Member Author

annevk commented Sep 14, 2021

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

@jakearchibald
Copy link
Collaborator

jakearchibald commented Sep 14, 2021

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.

@domenic domenic linked a pull request Mar 4, 2022 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: agent topic: browsing context topic: history
Development

Successfully merging a pull request may close this issue.

3 participants