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

Imperative allocation of agent clusters #4361

Open
annevk opened this Issue Feb 13, 2019 · 4 comments

Comments

2 participants
@annevk
Copy link
Member

annevk commented Feb 13, 2019

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

This comment has been minimized.

Copy link
Collaborator

rniwa commented Feb 22, 2019

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

This comment has been minimized.

Copy link
Member Author

annevk commented Feb 22, 2019

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

This comment has been minimized.

Copy link
Collaborator

rniwa commented Feb 22, 2019

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

This comment has been minimized.

Copy link
Member Author

annevk commented Feb 23, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.