Re: [w3c/permissions] Automation: "set permission" granularity (#181)

> We only want to test standard stuff.

I agree. [The specification has text that allows the user to control behavior at the granularity of a realm](https://w3c.github.io/permissions/#prompt-the-user-to-choose):

> 4. If the user chose an option, return it; otherwise return "denied". If the
>    user’s interaction indicates they intend this choice to apply to other
>    realms, then treat this this as new information about the user’s intent
>    for other realms with the same origin. 

Earlier in this dicussion, I framed this in terms of "completeness"; this is what I had in mind ([more background here](https://github.com/w3c/permissions/pull/151#discussion_r124188076)). If a web developer can write application code that reacts to this behavior, then the automation API ought to allow them to test that code.

It seems as though an objection to this level of granularity in the automation API would apply to the core specification. Do you think that spec text should be made more precise?

Maybe what's needed is a way for UAs to signal that they do not support this optional behavior. Would a change like this make sense?

```diff
-7. If parameters.oneRealm is true, let targets be a list whose sole member is
-   settings. 
+7. If parameters.oneRealm is true, then
+   1. If the permission state cannot be set for a single realm for any
+      implementation-defined reason, return a WebDriver error with WebDriver
+      error code "unsupported operation".
+   2. Otherwise, let targets be a list whose sole member is settings. 
 8. Otherwise, let targets be a list containing all environment settings
    objects whose origin is the same as the origin of settings. 
```

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

Received on Tuesday, 17 July 2018 16:54:13 UTC