Re: [w3c/permissions] Can permissions.setPermission not use context? (Issue #471)

cfredric left a comment (w3c/permissions#471)

I've been working with Jalon on this so I'll chime in with my understanding (but I'm happy to be proven wrong). TL;DR: the problem isn't that the remote end doesn't have access to an environment, it does. The problem is, that environment doesn't necessarily match what the client intended to use.

------ 

Prior to #390, every permission was keyed by the top level origin, so a single origin was sufficient to describe the "partition" of web content that a particular permission grant applied to. After #390, each permission could define its own key structure by overriding the `permission key generation algorithm` (among other things), which accepted an environment as input.

In #436, webdriver bidi clients gained the ability to explicitly specify the top-level origin to use when overriding a permission state in the remote end, instead of implicitly using the session's current browsing context. But there's a bug here: due to #390, a single origin is not enough to fully determine a permission key. For example, the `storage-access` permission key is a `{top level site, embedded site}` tuple. So, the single origin accepted by `permissions.setPermission` does not let clients provide enough information to create a permission key.

Additionally: the fact that `generate a permission key` algorithm accepted an *environment* caused another problem for webdriver bidi. A webdriver session does indeed have access to an environment (via the current browsing context), but if the client supplied an explicit `origin` for `permissions.setPermission`, then it doesn't really make sense to use the current environment when generating the corresponding permission key, since that would ignore `origin`. So #436 really ought to have given bidi clients the ability to supply an *environment*, or otherwise transform the passed-in `origin` into the environment that must eventually be fed to the permission key generation algorithm.

So, Jalon's PR was a fix for that, by updating the `permission key generation algorithm` to directly accept arguments that a bidi client can actually serialize (i.e. a pair of origins), and updating `permissions.setPermission` accordingly as well. That way, a webdriver client can either use the session's current environment implicitly (via non-bidi), or can specify some other key explicitly (via bidi).

@bvandersloot-mozilla, does that make sense or am I missing something?

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

Message ID: <w3c/permissions/issues/471/3440819717@github.com>