Normalize COOP inheritance with policy container

[domfarolino]

#9149 migrates Document's COOP into its policy container, while preserving the behavior of the original spec, however during development we knew about or discovered three odd scenarios where the current COOP inheritance needed to be tampered with outside of the usual policy container inheritance in order to preserve the current spec's possibly-wrong behavior. This bug is to track fixing these three cases in the spec as well as writing their associated tests.

1.) about:srcdoc

• The current spec uses a default-initialized COOP for all about:srcdoc navigations, however per Move cross-origin opener policy into policy container #9149 (comment), at least Chromium does not seem to distinguish between about:srcdoc and other iframes when determining if the initial frame's Document should inherit COOP. We should write tests to determine that about:srcdoc COOP inheritance exactly matches that of normal iframes, and change the spec accordingly. This would entail:
  • Tests for same-origin-to-top-level about:srcdoc iframes
  • Cross-origin variant of the above
  • Maybe: An about:srcdoc iframe that would normally be same-origin-to-top but isn't specifically because of sandbox flags, just to make sure that all ways of becoming cross-origin are treated the same

I guess we'd have to manually copy this conditional inheritance logic into this special case.

2.) Non-null navigation response (<embed> & x-mixed-replace)

• For this scenario, @antosart pointed out that my PR almost introduced a behavior change with the current spec. The current spec exclusively uses a fresh COOP for this scenario, but in reality we should probably perform the usual "only inherit the parent's¹ COOP if the frame is same-origin" dance.

I guess we'd have to manually copy this conditional inheritance logic into this special case.

3.) Create navigation params by fetching: scoping responseCOOP

• This feels the most important and therefore perhaps most broken case to me. Please see a lightly edited comment of mine below (original comment):

In #create-navigation-params-by-fetching, the current spec unconditionally stuffs responseCOOP in navigation params regardless of which policy container is selected by "determine the navigation params policy container". This seems wrong; instead we should probably scope responseCOOP to responsePolicyContainer. If we do this (i.e., limit the usage of responseCOOP to the usage of responsePolicyContainer), then whenever "determining the navigation params policy container" chooses a policy container other than responsePolicyContainer, the frame would inherit a different COOP than the spec currently gives.

The cases where "determining a navigation params policy container" would not choose responsePolicyContainer is:

• Navigation (not traversal) to local-scheme documents. In this scenario the current spec always uses a default-initialized COOP which is probably wrong. It feels like we should be inheriting the one from the initiator like the rest of the policy container.
  • To test this I guess we should have a non-default-COOP Document navigate a non-about:blank iframe to about:blank and confirm that when it opens up a pop-up, the popup's COOP depends on whether the iframe was same-origin to its top-level.
  • It might be good to also have one for data: URL iframes just to ensure that their COOP is never inherited when making a pop-up page, since their origin is always opaque
• Traversal (not navigation) to local-scheme documents; this is the historyPolicyContainer-is-non-null case. Probably we should be honoring/preserving the COOP in the session history entry (via the history policy container) instead of overriding it with responseCOOP (which is just a default-initiated COOP in the local traversal case) as the spec does today.
  • To test this I guess we should do the above-mentioned test case, and then do location.reload() in the iframe. This will trigger the traversal-initiated entry into #attempt-to-populate and should use the historyPolicyContainer in https://html.spec.whatwg.org/#populating-a-session-history-entry:determining-navigation-params-policy-container-2. If we don't use location.reload() in the about:blank iframe, then we'd have to navigate away from the Document and then back, but I don't think we can do this reliably and trigger this logic, due to bf-cache.

/cc @antosart @hemeryar @camillelamy @domenic

I'm happy to do the spec work for this once #9149 lands. Help with the tests from policy container/COOP experts would be greatly appreciated.

Footnotes

1. "Parent's" COOP specifically because I don't think an <embed> object can have an initiator of any other kind, since there is no contentWindow handle or anything. Only a src attribute, and sourceDocument is always the parent Document in the embed navigation case ↩