Clarify how "child browsing contexts" works

[domenic]

As noted in #1312 (comment), current usage is ambiguous. The spec says:

If the browsing context container element E is in the Document D, then P is said to be the parent browsing context of C and C is said to be a child browsing context of P.

i.e., it defines "browsing context C is a child browsing context of browsing context P".

Later the spec says:

Because they are nested through an element, child browsing contexts are always tied to a specific Document in their parent browsing context.

In practice, how the phrase "child browsing context" is used is usually by referring to a document's child browsing contexts, or sometimes a window. This is not really well-defined.

Later in the spec when defining window.length, it says:

The number of child browsing contexts of a Window object W is the number of child browsing contexts that are nested through elements that are in a Document that is the active document of the Window object's associated Document object's browsing context.

This concept of "child browsing contexts that are nested through elements that are in a Document" maybe is equivalent to "the document's child browsing contexts", but I am not sure. Later, in [[GetOwnProperty]] for WindowProxy, the spec uses

the indexth child browsing context of the Document that is nested through an element that is in W's Document, sorted in the order that the elements nesting those browsing contexts were most recently inserted into the Document, the WindowProxy object of the most recently inserted browsing context container's nested browsing context being last.

---

I'd suggest centralizing these definitions and defining:

• C is a child browsing context of P
• A Window object's child browsing contexts (an ordered list) + the number of child browsing contexts of a Window W (which should be the cardinality of that list)
• A Document object's child browsing contexts
• A Document object's descendant browsing contexts
• Optionally: a Window object's same-origin child browsing contexts (could be used for "child browsing context name property set")

Then an audit should be done of all places in the spec that use "child browsing context" to see if we can re-frame them in terms of one of these definitions. E.g. I think [[GetOwnProperty]] should use the Window object's child browsing contexts.

I could work on this but maybe @annevk wants to give it a shot?

[annevk]

Optionally: a Window object's same-origin child browsing contexts (could be used for "child browsing context name property set")

Cannot be used for that purpose as discussed in #1337.

We should also more clearly define that E has a browsing context internal slot that can be either null or a browsing context.

[annevk]

I think you ended up cleaning this up, but I can't find all the commits. 7b56772 seems to be one of them.

[domenic]

It looks like some of the issues were solved, but the fact that we still talk about a document's child browsing contexts or a Window's child browsing contexts remains. It should be pretty easy to clean up though now. Maybe I can give it a go soon.

[annevk]

I think this is a subset of #5020.

[annevk]

Basically whenever we use child browsing context in a hierarchical way there's an issue of sorts. And it would prolly make sense to give documents a child browsing context collection of sorts.

• Discard all the child browsing contexts of document.
• The term plugin refers to a user-agent defined set of content handlers used by the user agent that can take part in the user agent's rendering of a Document object, but that neither act as child browsing contexts of the Document nor introduce any Node objects to the Document's DOM.
• Abort the active documents of every child browsing context.
• Investigation requested for beforeprint/afterprint #5096
• Scroll restoration only talks about child browsing contexts #5103

[annevk]

@domenic did 7b4964a sufficiently improve this in order to close this issue?

[domenic]

I just did a re-audit and, upon finishing it, realized the results are the same as your comment in #1336 (comment) .

We should be able to fix the discard and abort cases pretty easily. We could leave the plugin case alone for now. And then use #5096 and #5103 to track the remaining. But, I don't think we should close this until we fix the discard and abort cases.