Imperative allocation of agent clusters

[annevk]

This is a follow-up to #4198. The browsing context group concept is added by #4350, but to properly clarify the lifetime of objects, we'll need to imperatively allocate them. In particular, objects might lose their direct connection to a browsing context (e.g., when you remove an <iframe>), but that doesn't mean they're outside the scope of the agent they were created in (e.g., when you keep a reference to a WindowProxy object while you remove that <iframe>).

(Alternatively we could perhaps give everything a pointer to the browsing context group, but that doesn't seem like a good architecture, in particular because nothing in ECMAScript really supports that kind of notion.)

This is the setup I have for this thus far:

---

A browsing context group has associated agent clusters (a map of agent cluster key/agent cluster).

An agent cluster key is an origin or a scheme-and-site. A scheme-and-site is a tuple of a scheme and a domain.

To obtain an agent cluster key, given an origin origin, run these steps:

1. If origin is an opaque origin, then return origin.

2. If origin's host's registrable domain is null, then return origin.

3. Return (origin's host's scheme, origin's host's registrable domain).

To obtain a similar-origin window agent, given a browsing context group group and agent cluster key key, run these steps:

1. Let agentCluster be the result of obtaining a browsing context agent cluster with group and key.

2. If agentCluster does not contain an agent, then add a new similar-origin window agent to it. (ECMAScript does not define the layout of agent clusters unfortunately.)

3. Return agentCluster's similar-origin window agent.

To obtain a browsing context agent cluster, given a browsing context group group and agent cluster key key, run these steps:

1. If group's agent clusters[key] does not exist, then set group's agent clusters[key] to a new agent cluster. (ECMAScript does not define allocating agent clusters unfortunately.)

2. Return group's agent clusters[key].

---

Feedback appreciated.

cc @mystor @farre @rniwa @creis @domenic

(This intentionally does not cover workers. They can use a simpler allocation setup that can be sorted as part of #4339.)

[rniwa]

but that doesn't mean they're outside the scope of the agent they were created in

It's true that the script from one agent X may hold onto an object O from another agent Y but if Y dies, there is no more execution context or stack left for Y. We can't, for example, start evaluating or dispatching events in Y.

At least in WebKit, each document has its own script execution context only when it's associated with a frame (i.e. a browsing context) and when it gets detached from a frame, its script execution context and therefore the agent associated with it is dead.

I'd be curious to know how Gecko is architected here.

[annevk]

How can you hold onto objects cross-agent? The only thing that's cross-agent is a Shared Data Block per ECMAScript. Do you mean cross-realm/global? Also, to clarify, the case OP is talking about is same-origin <iframe>s.

[rniwa]

Yeah, I'm talking about cross-realm/global case. In general, the life cycle of an agent is tied to its document having a frame. As soon as it loses the frame, the agent is gone.

[annevk]

I don't understand. In the case of a document having a same-origin framed document, both documents have a global. That global points to a single (shared) agent. Removing the frame doesn't get rid of the agent.

[domenic]

This is nearing completion in #4617. Although the title of the issue is pretty general, seeming to cover all types of agent clusters, it sounds like we should be closing this issue and using #4339 to track worker and worklet stuff.