WindowProxy/Location and agent clusters

[annevk]

After #4361 I suspect we'll still need to cleanup how we deal with WindowProxy and Location objects as we currently hand them out across agent cluster boundaries.

Effectively, they both need individual proxy objects ("WindowProxyProxy" or some such, indeed) for each agent cluster that can access them (they can be the actual objects if they're in the same agent cluster).

Perhaps this can be done with a map and some logic on browsing contexts.

This can then also define exactly how the messaging between agent clusters is to take place. And since these proxy WindowProxy/Location will be forever not same origin-domain, they can also be simpler in a way (no need for security checks, though ideally behave identical except for messaging).

(Note that we cannot remove the security checks for the objects within an agent cluster as an agent cluster can still span several origins, just not sites.)

[domenic]

Can you explain the problem more? I don't understand what's wrong with the current setup. When do we hand them out across agent cluster boundaries?

[domenic]

@annevk clarified offline the problem is when you access a cross-origin-domain iframe's .contentWindow property. Concretely, given

<!-- https://example.com/ -->
<iframe src="https://example.org/"></iframe>
<script>
const windowProxy1 = frames[0].contentWindow;
</script>

<!-- https://example.org/ -->
<script>
const windowProxy2 = window;
</script>

Then currently we use the same spec-object (which is theoretically 1:1 with JS object) to represent windowProxy1 and windowProxy2. But, they are not the same JS object; they do not even have to live in the same process, since they are cross-agent-cluster.

This is not observable because there is no way you could ever get those two objects into a place where they could be compared with ===. But, it's still a mismatch between spec architecture and implementation.

I'd lean toward figuring out a lightweight way to do this without disrupting too much of the spec ecosystem. (For example, it'd be kind of terrible if everything had to start talking about WindowProxyProxys instead of Windows or WindowProxys.)

E.g., maybe we could say that the difference happens at the binding layer? So that we use the same IDL WindowProxy across multiple agent clusters, but when you convert that IDL platform object to a JS object, we get two distinct objects? Not sure how crazy that is.