[webkit-dev] Web Notifications API

[Jon Lee]

On Feb 8, 2012, at 5:41 PM, John Gregg wrote:

> 3. Use static functions on the notification constructor for permissions checks.
> 
> By moving them there, it allows us to remove window.webkitNotifications and the NotificationCenter class, cleaning up the API.
> 
> I think that would be consistent with moving from a factory model to a constructor model.  The Feature-permissions effort was intended to create a common interface for handling permissions, but it may still be too far off and sticking with a scoped approach is more practical.  The only concern is that it is an implementation change that only partially reaches what has been spec'd, which might leave some continuing confusion among users of Notifications as to the authoritative version of the interface.

Which missing aspects of the Feature permissions spec are you concerned about?

> 4. Adjust the permission functions.
> 
> WebKitNotification.permissionLevel() --> String
> 
> Similar to checkPermissions(), synchronous call. The name aligns with similar functionality in the DAP Feature Permissions spec [FEAT], but scoped specifically to Web Notifications. Returns one of three strings: "granted", "denied", and "default". This follows the current best practice from the WebApps WG where strings are being used instead of enums.
> 
> WebKitNotification.requestPermission(callback)
> 
> An asynchronous call, as it is currently. The callback specified includes one argument which represents the permission, similar to the return values in permissionLevel(). (Currently it is just a void callback.) If the user had already made a policy decision, then the callback is invoked immediately (with either "granted" or "denied"). Otherwise the UA may ask the user for permission, and the callback is invoked when the user makes a decision (cancelling the request does not invoke the callback). Any notifications posted in the meantime would be queued until then. Multiple calls to this function should just result in one visible request.
> 
> This matches the FeaturePermissions spec with the exception of the decision as a parameter, which is reasonable though redundant since the current permission level is already easily read.  The queueing of notifications discussed later.

It could work either way. But for me, it seems weird from a programming flow perspective to have to explicitly fetch the level again within the callback; I would expect the response to be included in some form as an argument.

> 
> 5. Remove replaceId.
> 
> This could already be done by canceling a previous notification and posting a new one. The idea of replacing a notification with another one without alerting the user is a feature that we don't intend on supporting.
> 
> Just so the use case is clear here, it is not equivalent to canceling and showing from the webapp's perspective, though it is to the browser.  The reason for replaceId is when the same application (e.g., Gmail) is open in multiple browser windows.  When a new message arrives, both tabs will discover this and lacking communication between them, attempt to show a notification.  But if both notifications are tagged as corresponding to the same real-world event, they are seamlessly merged and the user only sees one.

But in this case, wouldn't the second notification just be ignored, instead of replacing the first notification?

Also, does Chrome keep track of IDs that have been shown, even after the notification has been closed? For example, if one page gets the new email before the other, it posts a notification, the user clicks on that notification, and the page closes that notification _before_ the other page has had a chance to query Gmail's servers for new emails, does Chrome still remember that a notification of that ID was posted before?

Or does this only apply for notifications that are shown but not closed?

> 6. Improve show() behavior.
> 
> Calling show() when the site has been denied permission should call onerror(). If no decision was made, then the notification should remain queued, and only until after the user has decided should onshow() or onerror() be called. I also think show() can only be used once. Subsequent invocations should call onerror().
> 
> The permission-denied behavior you want is as spec'd (error event).  The permission-unknown behavior you propose seems more difficult for authors, since at the point of calling show() it would be impossible to distinguish between being queued for space limitation and being queued waiting for permission.  If you limit this to the case where requestPermission() has already been called, as opposed to any permissionLevel=unknown state, that might make more sense.  We could even introduce a new constant for permissionLevel of "request-pending" which would make this easy to specify cleanly.

I think authors should use available API. So those who choose not to use requestPermission() end up having to deal with that ambiguity. Also, why does that ambiguity need to be differentiated? How would a website change its behavior based on that knowledge?

Thanks!
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120209/9ad8eaf1/attachment.html>