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.

I always forget how awful `document.domain` is. That said, @lgarron pointed out that Chrome does something even weirder with permission storage: a bunch of permissions are stored with a wildcard domain, so multiple origins can match the same entry in the permission store: https://code.google.com/p/chromium/codesearch#search/&q=function:ContentSettingsPattern::FromURL$%20file:.cc

I'm now inclined to put the lookup of the settings object in [get a permission storage identifier/key](https://rawgit.com/jyasskin/permissions/update-permission/index.html#get-a-permission-storage-identifier) and downgrade the MUST to a SHOULD to let the value match current practice. We can tighten it back up as we write tests for current browser behavior and/or fix browsers to do something more sensible.

---
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#r61336590