- From: Andrew Wilson <atwilson@google.com>
- Date: Thu, 24 Oct 2013 13:42:12 +0200
- 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