Can permissions.setPermission not use context?

[annevk]

#468 and #469 this API was changed and the motivation seems to be a WebDriver requirement, but @bvandersloot-mozilla suggests WebDriver doesn't need this and would in fact have access to an environment. So what's going on?

(privacycg/storage-access#233 is also related to this.)

cc @jalonthomas @johannhof

[cfredric]

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?

[johannhof]

(FWIW this makes sense to me)

[bvandersloot-mozilla]

I think that makes sense, but it would be nice to support using the environment where the origins are not supplied, as is done in the tests right now. Failing that, an update to the tests to match this behavior would probably be needed, but I don't particularly like that in October of Interop.