Re: [w3c/permissions] Define an algorithm to update the permission storage. (#91)

> +    <h3 id="storage-manipulation">Storage Manipulation Algorithms</h3>
> +
> +    <p>
> +      Other specifications can use the algorithms defined in this section to
> +      manipulate the <a>permission store</a> from their algorithms.
> +    </p>
> +
> +    <div class="example" id="example-storage-manipulation">
> +      <p>
> +        The [[notifications]] API can check for the user having granted
> +        permission using:
> +      </p>
> +      <blockquote>
> +        If the {{"notifications"}} <a>permission's state</a> is not
> +        {{"granted"}}, reject <var>promise</var> with a {{TypeError}} exception
> +        and terminate these substeps.

In all the uses of permission state, I couldn't find one where it pulled the origin out of anything but the current/entry/incumbent settings object, so I factored that into ["name" permission's storage](https://rawgit.com/jyasskin/permissions/update-permission/index.html#permissions-storage) so we don't have to re-state it everywhere. I could have you pass the current settings object explicitly, if you think that makes the usage clearer.

Given https://noncombatant.github.io/permission-delegation-api/, it's not guaranteed that the key's always going to use the *origin* of the current settings object: it might use the origin of its embedder along with some flags on the iframe instead.

---
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/pull/91/files/315ae14c94bbc7cc55126faa1dfb4d3a7a26e89a#r61119751