[webkit-dev] Notifications API

[John Gregg]

On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 22, 2009, at 10:19 AM, John Gregg wrote:
>
> Sure.  We have the following plan for how to handle opt-in:
>  - Use of the feature by script, if permission isn't granted to the origin,
> should throw an exception, not present permissions UI.  So your insistent
> porn site would have no effect on the user.
>  - A dialog box asking for permission should only appear in response to a
> user gesture like a click.  So in the normal case, an application will
> present a user with a link "New: Desktop Calendar Notifications available!
> Click here to setup."  And that link will present a prompt from the
> user-agent "Do you trust calendar.com?  The site wants to display
> notifications on your desktop.  [Yes/No]"  If the user says yes, script
> running under that origin will have permission to show desktop
> notifications.
>
>
> To expose this flow, wouldn't you need a method in the API exposed to
> JavaScript that requests permission for notifications, rather than actually
> posting a notification? I don't see such a method in the submitted patch. It
> would not make sense for a link labeled "New: Desktop Calendar Notifications
> available!  Click here to setup" to actually display a notification itself,
> I wouldn't think.
>
> Having a JavaScript API to request permissions, along with plumbing through
> the WebKit layer to allow a WebKit embedder to suitably prompt the user,
> would address most of my concerns.
>

Yes, this would be necessary.  It's actually part of the spec API I
originally proposed at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html("readonly
bool trusted" attribute and "void requestTrust()" method), and I
was planning to submit in a follow-up patch.  But if you prefer it come in
at the same time as the rest of the code, it can be done all at once.  Do
you have any particular proposal for how to accomplish the "plumbing"?
Part of the thinking is that it would be nice to avoid overwhelming users
with lots of different permission UIs for individual native-app-like
features that will come up (persistent workers (if and when) & local
database quota come to mind).

Thanks,
 -John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/34e9d4b2/attachment.html>