Add some sort of navigation-params container to stop threading stuff through navigation-related algorithms

[domenic]

We currently have a serious problem with threading things through the navigate algorithms, and I would love some sort of container to make it better. This has come up a lot with COOP, and e.g. #5518 runs into it as well.

Concretely, a bunch of interesting setup stuff happens in create and initialize a Document object: it creates some combination of browsing context group, browsing context, agent cluster, agent, realm/Window, and Document. To do this, it needs the following data:

• document type (XML or HTML)
• content type
• request
• response
• browsingContext (which one? not immediately clear from the algorithm... sometimes it gets overridden)
• sandboxing flag set
• origin (not clear precisely which one)
• incumbent navigation origin
• active document navigation origin
• reserved environment (can be null)
• cross-origin opener policy
• browsing-context switch needed boolean

These values then need to be threaded through many places:

• They usually originate in the main navigate algorithm
• They end in either "process a navigate fetch" or directly in "process a navigate response"
• They then get passed through, unchanged, to 6x "page load processing model for X" algorithms
• Those algorithms finally call "create and initialize a Document object"

I think we should create some sort of container struct for these values, which is created in the main navigate algorithm, might get mutated a bit in navigate/process a navigate fetch/process a navigate response, and then gets passed through unperturbed to "page load processing model for X" and "create and initialize a Document".

This should be significantly clearer, and much more maintainable. The cost will be some rebasing for #5518 (/cc @camillelamy), but I can probably help with that.

[jugglinmike]

Introducing a struct like that would also make the algorithms' descriptions a little more vague. Instead of a precise list of each algorithm's dependencies, we'll have a general sense of what each might reference. Kind of like add(x, y) versus add(objectWithFifteenProperties).

The "passed through unperturbed" part is really important because it gives readers confidence that values aren't being switched out from the call site. We get that "for free" when invoking algorithms with explicit parameter values. Would we explicitly communicate the invariant whenever it held for the new struct?

As a drive-by contributor, I'm definitely more tolerant of the maintenance burden imposed on full-time editors, so take this with a grain of salt. I wanted to at least recognize these drawbacks to fill out the discussion.

[domenic]

Interestingly at this point "create and initialize a Document object" no longer uses incumbentNavigationOrigin and activeDocumentNavigationOrigin; those are threaded through several levels for no benefit. Some refactoring must have used them up earlier.

[camillelamy]

It would be helpful indeed! When writing the COOP spec PR it was hard to keep track of all the places I was supposed to add/pass a parameter. In fact, it's probably this PR which removed usage of incumbentNavigationOrigin and activeDocumentNavigationOrigin inside "create and initialize a Document object" but missed the fact that all those call sites needed to be updated.