Initializing a document from a response

[annevk]

One problem I keep running into is to how exactly initialize a document. The way we do this at the moment is not very principled.

initial about:blank response: state comes from the creator browsing context (parent, opener, or missing) and in particular, if not missing, its active document.

about:blank URL response: state comes from the response, which is put there by Fetch, sometimes (from source browsing context's active document).

about:srcdoc response: state comes from the response which is put there by HTML, sometimes (from the parent browsing context's active document).

blob/data URL response: state comes from the response, which is put there by Fetch, sometimes, e.g., whatwg/fetch#306 is not (again, from source browsing context's active document's relevant settings object). (Though note how origin is set weirdly different.)

javascript URL response: state comes from the navigated browsing context's active document.

HTTP URL response: state comes from the response, not really a problem.

This is a giant mess. I don't think we should continue with this setup. Adding state in lots of places is very error prone. We have a couple of responses for which we need to inherit state and we should just define that inherited state in a single place, including where it originates. Most sensible seems parent or opener, and if those don't exist some kind of default.

[shhnjk]

HTTP URL response: state comes from the response, not really a problem.
Does redirect response has a Document (and more interestingly, active document)? I saw a spec where this is an issue 😄

[annevk]

@shhnjk a response with a redirect status should never have a document (unless it doesn't have a Location header or some such). Navigate follows redirects before creating a document.

[shhnjk]

Thanks, I will let spec editor know about the issue!

[domenic]

I think this might be closable now, as the introduction of navigation params bundles things together, and in general I think document creation is pretty well nailed down? /cc @domfarolino for a third opinion.

[annevk]

I suspect #4926 will address this. (Though maybe not the page loading aspects where we start an HTML parser and such in various ways.)

[domfarolino]

I'd say that the Policy Container work will indeed cover the initialization and potential inheritance of policies on a document, but otherwise I'd say that we can close this and track the remaining bits from that bug. This seems pretty solid in the spec these days % policies.