Pass a top-level navigation initiator origin to Fetch

[bvandersloot-mozilla]

To un-logjam the cookie layering work, I've started whatwg/fetch#1807. That depends on this info to be piped into Fetch so we can actually specify in WHATWG what SameSite=Strict means.

This patch plumbs that through on top-level navigatable fetches.

This doesn't build because it relies upon the corresponding patch in Fetch. Let me know to land these.

• At least two implementers are interested (and none opposed):
  • Mozilla
  • Apple? (@annevk)
  • Google? (@johannhof )
• Tests are written and can be reviewed and commented upon at:
  • change is not observable, not needed?
• Implementation bugs are filed:
  • change is to update spec interfacing, not needed?
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed:
  • I don't think this is needed?
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/infrastructure.html ( diff )

[annevk]

cc @johannhof

[annevk]

I think one thing we identified that's worth looking into here is what happens if OPENER opens POPUP and then attempts to navigate POPUP's EMBED using named targeting.

[bvandersloot-mozilla]

I think one thing we identified that's worth looking into here is what happens if OPENER opens POPUP and then attempts to navigate POPUP's EMBED using named targeting.

Looking into this, I think the only interesting case here is where OPENER is cross-origin to POPUP, because it is exactly this case where you have a non-ancestor initiator. This isn't possible to do because targeting is blocked by the cross-origin-ness of the opened window. We could test where OPENER and POPUP are same-origin, but that just feels like the existing iframe tests with extra steps. Let me know if you see anything worth testing here, but I don't see it.

[annevk]

This looks in order now from my perspective.

[annevk]

I'm going to land the PRs identified in #9000 (comment) (including this one) soonish. We have reduced the scope to essentially only tackle the new way we integrate with Cookies at the IETF (and only for the Cookie and Set-Cookie header at this point). So in effect this should be a non-normative change.

PRs building on top of this work will need to fill out the PR template completely however.