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

Re: [whatwg] The behaviour of Notification.requestPermission() in Workers

From: Andrew Wilson <atwilson@google.com>
Date: Thu, 24 Oct 2013 13:42:12 +0200
Message-ID: <CAArhhit1GF9gAZ9_GxaFfju2-nTeMYfP+vq9xCV0J_Z_VKoV_A@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>, Nikhil Marathe <nsm.nikhil@gmail.com>
Agreed with Anne - I don't see the value in exposing a non-functional
requestPermission().

Certainly on Chrome (which only allows invoking requestPermission in the
context of user input to prevent abuse) we would be unlikely to support
requestPermission() from workers, at least unless we decide to change that
behavior.


On Thu, Oct 24, 2013 at 11:05 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> On Thu, Oct 24, 2013 at 2:19 AM, Nikhil Marathe <nsm.nikhil@gmail.com>
> wrote:
> > The easiest solution for implementors and authors is to make the
> > requestPermission() call in a HTML page before spawning a worker or
> > registering a service worker. Inside the Worker scope we then have two
> > options:
> > 1) requestPermission() is not defined.
> > 2) requestPermission() does not ask the user, but uses the permission
> > associated with that origin, or denied.
> >
> > I believe option 2 is better in terms of having a complete API.
> >
> > Feedback is appreciated about what the right approach should be.
>
> Given that Notificaiton.permission exists, I'm not sure what the
> additional value of Notification.requestPermission() in a worker
> context would be.
>
>
> --
> http://annevankesteren.nl/
>
Received on Thursday, 24 October 2013 11:42:40 UTC

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