W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

Re: [whatwg] Notifications: making requestPermission() return a promise

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 8 Oct 2014 08:59:29 -0700
Message-ID: <CAAWBYDB-XtbXxAj1YepyJz_dhRHEQLiPT_=HK=93n40airzpSA@mail.gmail.com>
To: Tobie Langel <tobie.langel@gmail.com>
Cc: Andrew Wilson <atwilson@google.com>, WHATWG List <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel <tobie.langel@gmail.com> wrote:
> On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>
>> The question is whether it's not natural to assume that *if the promise
>> fulfills*, that means they got permission. This allows them to do things
>> like using Promise.all() to join multiple permission requests together and
>> get a nice combined promise that fulfills when everything succeeds,
>
>
> This is as simple as:
>
> Promise.all(permissionRequests).then(function(results) {
>     if (results.every(x => x === "granted")) // …
> });
>
> But I don't think it's the right approach to handling permissions in
> general. Developers should handle granted permissions as progressive
> enhancements, not balk when they don't get all the permissions they
> required. Using exceptions for denied permissions sends a completely wrong
> message imho, especially when it's combined with Promise.all.

I don't think moral arguments really have a place here.  Whatever
mitigation code that authors write to handle failed permissions can go
in the reject handler exactly as easily as in the fulfill handler.
That we believe authors should handle permission failures
intelligently doesn't, itself, mean that we should make the success
path less convenient.

~TJ
Received on Wednesday, 8 October 2014 16:00:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC