Re: [w3c/permissions] Add an optional `topLevelOrigin` parameter to the `permissions.setPermission` command (PR #468)

cfredric left a comment (w3c/permissions#468)

If I may chime in - the issue that Jalon's trying to fix is that step 2 of `set a permission` grabs all of the ESOs that are _same-origin_ with `target origin`.

The usage of `same-origin` was fine up until #390, when it became possible for permission "scopes" to deviate from an origin, via the concept of `permission key`. But importantly, #390 didn't update the `Set Permission` command to use a `permission key` instead of an `origin`. (I haven't dug through the whole PR, but I suspect this was an unintentional omission.)

This means it's no longer possible for WebDriver to precisely override the permissions states for permissions whose key type is not the default, i.e. aren't origins. For example, WebDriver cannot request that the `storage-access` permission state should be overridden for siteA iframes that are embedded in siteB (but not for any other iframes).

Jalon's PR is meant to fix this by allowing WebDriver `remote end` to receive two origins, compute a `permission key` from them, and then use that key to choose which ESOs get the new permission state.

This is why the PR modifies the key generation algorithm: so that the WebDriver `remote end` can construct a `permission key` from the command's pair of origins and then use the key to affect specific ESOs.

-----

(Side note -- I don't really understand step 4.1 of `set a permission` in the current spec. Is it possible this step should have been changed when the `permission store` concept was introduced?)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/pull/468#issuecomment-3310082034
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/permissions/pull/468/c3310082034@github.com>