Use the newly exposed methods to initialize feature policy.

[dtapuska]

Instead of delegating to the feature policy spec to initialize feature
policy after the document is created initialize feature policy first
and pass it into the constructor of the document.

---

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

[dtapuska]

This requires w3c/webappsec-permissions-policy#324 to land first though.

@clelland PTAL

[dtapuska]

@annevk WDYT?

[clelland]

This looks reasonable; I can't see any obvious issues with this ordering. (And I just merged w3c/webappsec-permissions-policy#324, so we can call the algorithms this way)

[domenic]

LGTM, seems like just an editorial change. Will give @annevk another day or so if he wants but I think it's pretty simple.

[dtapuska]

I'd like both spec editors to be aware of this pattern I'm introducing. Constructing things before the Document is created. The current COEP proposal and CSP also suffer from this same problem that feature policy had, those will need to be fixed at some point.

[annevk]

So the reason the browsing context is passed in is to look at ancestor browsing contexts?

I don't quite like that this means we'd have to potentially do cross-process messaging thrice. Once to start the navigation and then twice more to get additional data. I think Ideally "navigate" is passed all the state it needs at navigation time.

Another thing with this setup is that it means that Feature Policy (or whatever we end up calling it) ends up being strictly less powerful than COOP, which can cause the browsing context to be replaced. This is probably okay for now, but perhaps worth revisiting at some point.

(Another concern I have is that there's no mutual agreement on much of Feature Policy at this time, so this goes against the WHATWG Working Mode a bit, but I'm not going to block this on that.)

[dtapuska]

This change is definitely purely editorial and the issue currently exists in the current spec. Yes the browser context determines inheritence. I believe the fact how cross-process messaging is done is an implementation detail. In Chrome we have the feature policy on the frame tree, so it is mirrored into every process so the query of inheritence is not a cross-process call.

[annevk]

The main problem I have with the model is this timeline:

1. You navigate the child.
2. Some time later but before the child is navigated you change state in the parent.
3. The child finishes up navigation, does the changed state since the act of navigation take effect? I think it would be bad if it did as it's highly non-deterministic. (I realize that in the specific case of Feature Policy this might not matter (yet), but you asked about the general setup and I replied to that.)

If you want to land this change and track the problem separately, that's okay with me, but I don't think we should ignore it.

[clelland]

@annevk, would you prefer to see a model where initiating the navigation bundles up all of the state at that time that will be needed to eventually create the new document?

You'd mentioned something along those lines in w3c/webappsec-permissions-policy#256, and it's probably worth fixing at some point.

As long as we can define exactly which statements trigger navigation, and when that gets snapshotted (on "process the iframe attributes", or at the end of the current JS function, or whether we queue a microtask), then we should be able to get rid of the race.

[annevk]

Yeah, I think we are there (at least planning-wise) so we can start doing this.

[annevk]

Happy to see this land with my newline removal.