W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Notifications

From: John Gregg <johnnyg@google.com>
Date: Fri, 5 Feb 2010 14:58:54 -0800
Message-ID: <5ce7a0db1002051458w2214fdb7o414bd0c7fd2984d7@mail.gmail.com>
To: Drew Wilson <atwilson@google.com>
Cc: Anne van Kesteren <annevk@opera.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
On Fri, Feb 5, 2010 at 10:19 AM, Drew Wilson <atwilson@google.com> wrote:

>
> One possible alternative to an explicit requestPermission() API would be to
> instead just have the browser display permissions UI the first time the user
> calls createNotification(). An application that wants to get permission in
> advance could just call createNotification(), but then never actually call
> show() (or, perhaps they could just display a confirmation notification like
> "Desktop notifications are now enabled for FooMail"). As someone who has
> integrated notifications into a web app, I have to say that I found the
> explicit API useful, but I'm not currently using the callback for
> requestPermission() so an alternate API could work so long as there was some
> way to initiate a permission grant without actually displaying a
> notification.
>
>

This (permission request on first-use) was discussed before.  The concern
was that if we are going to have a permissions flow, it should be
user-initiated, or the site will have the ability to annoy the user by
popping up unsolicited browser UI.  For this reason the spec requires a user
gesture to call requestPermission().  If we request permission on first use,
we again allow unsolicited permission dialogs, which I think is bad.

 -John
Received on Friday, 5 February 2010 22:59:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT