Bugs/lacking clarity in 9.5, 9.6: Algorithm lacking realms

[theIDinside]

The following algorithms have steps that are not possible to resolve:

• 9.5 Create a Permissions Policy for a navigable
• 9.6 Create a Permissions Policy for a navigable from response

These are two algorithms that specify how to create permissions policy. Permissions policy object's, are specified to have an associated node. But in these algorithms, we are not provided with one.

To make sense from a spec perspective I think these need to take an associated node argument. How should the policy object be created otherwise, what realm, etc?

The problem though, with this is creating and initializing a new document, has step 2 as its "create permissionsPolicy from ..." - at that point there is no associated node, because the document in that algorithm hasn't been created yet and isn't created until step 9.

This spec probably needs changing to keep it from being in direct contradiction with itself or add something like:

"When document has been created, associate permissionsPolicy's associated node with document", but that obviously would be changes to that spec, and not this one (I think, probably, this will require changes to both specs, as I don't see how one can sneak in a "associate node N with permissionsPolicy" otherwise).

[clelland]

There's a difference between a Permissions Policy and "The permissionsPolicy object".

(Unfortunately similarly named)

The first is the abstract object which represents the policy, and it's what we're creating in those algorithms 9.5 and 9.6. It doesn't need a node; it isn't associated with a JS environment; it's created even before we start to parse the document itself, I believe.

The second one is a JS object. It's the result of accessing document.permissionsPolicy (still frustratingly spelled document.featurePolicy in Chromium), or <some iframe element>.permissionsPolicy, and its associated node in this case is either document or that iframe element.

• https://w3c.github.io/webappsec-permissions-policy/#document-policy-object: "Each Document has a policy object, which is a PermissionsPolicy instance whose associated node is that Document."
• https://w3c.github.io/webappsec-permissions-policy/#iframe-policy-object: "Each iframe element has a policy object, which is a PermissionsPolicy instance whose associated node is that element."

[theIDinside]

Thanks for response, that made it a bit clearer for me. But I still have questions regarding the creation of the policy object instance, at least for iframe elements.

For documents we create the policy object, the creation of it is defined to be either in creating a permissions policy from a response algorithm or Create a Permissions Policy for a navigable

but when searching through the HTML spec at large, I can't seem to find any mention of how/when the policy object (the JS object, that is) for an <iframe> is supposed to be instantiated? If this is not spec'ed when is it supposed to be instantiated? Or is this just intended to be created lazily when first accessed via <iframe>.permissionsPolicy? If so, this probably should be spec'ed somehwere?

Edit, for instance,
"post connection steps" for an iframe element, specified here instructs the user agent developer to eventually call Create a Permissions Policy for a navigable - but nowhere in these steps is it explicitly laid out that <iframe> should have it's permissions policy object, instantiated at this time, though it is probably the most appropriate time, right?

[theIDinside]

And it isn't just the policy object that is not specified for the <iframe> but also the "permissions policy" isn't specified either. It's the parts specific to <iframe> that is undefined.