Browsing context hierarchy needs to go through the embedding document

[annevk]

Grabbing the parent browsing context or top-level browsing context is rather problematic. In particular when then their active document or some such is consulted.

@bzbarsky has raised this many times.

To prevent these kind of issues we should make browsing contexts explicitly point to their embedding element and make all traversal go through that and then define convenient short hands for top-level document, parent document, and such.

This would also help with defining new concepts such as top-level origin, without having to explicitly forward such state downward.

[annevk]

Example: if you navigate a popup from A to A' and A embeds B and A' does not, when you arrive at A' and look at B's window.parent and window.top they are null in all browsers, but it's not necessarily true that B doesn't have an associated browsing context (depends on bfcache).

This issue is related to browsing context's "sleepy state" not being defined. In particular if you go back from A' to A and A was in the bfcache, the browsing context from B is still there and cannot have been discarded, but this is not really defined either way. In part I suppose whether we need to resolve this depends on how bfcache ends up being designed, but I suspect we will need to solve it given what existing user agents are iterating towards.

[domenic]

I'm not sure this is as simple as always going through the embedding document. In particular, the embedding document is cross-process is many cases. So for example, the spec has lots of "ancestor" or "descendant" checks. Such as:

• Navigation sandboxing depends on whether the source/target of the navigation have an ancestor relationship
• User activation propagation needs to propagate throughout the tree, to both ancestors and descendants

We cannot go through the document and the browsing context container in such cases, as they're happening "in the browser process" (i.e. in parallel, or in a global way, not connected to any specific document). In implementations, there's a source of truth for what the browsing context hierarchy looks like in this browser process.

So I think we're going to continue needing to use terms like "ancestor" and "descendant" which are defined in similar ways to how they are defined today, and assume there's a global view of the browsing context hierarchy.

That said, we still definitely need to fix the "sleepy state" / bfcache issue you mention, and that can be done.

And, in the simpler cases, we can use the explicit container and parent pointers, instead of the vague global-view ones.

[annevk]

We are explicitly ignoring the process boundary in many cases, why is it important here? You argued before in favor of ignoring it. I agree it might be better to not ignore it, but that would also require redesign of many things that cross the agent cluster boundary, including objects such as WindowProxy and Location.

[domenic]

I think I'm drawing the line at accessing specific HTML elements (e.g., containers) across processes. Doing so is pretty incoherent, and trying to move from the current setup (which roughly matches implementations, i.e. they have a global source-of-truth in the browser process) to one that pokes at elements across processes (which is not something implementations do) is not an improvement, like this issue seems to imply it is.