[webkit-dev] Web Notifications API

[Jon Lee]

Hi! Lots of responses below (mashed previous replies together for topic coherency):

John Gregg wrote:
> Which missing aspects of the Feature permissions spec are you concerned about?
> 
> I was only referring to the fact that the spec calls for a separate generic interface for permissions with a parameter that identifies the feature [FeaturePermissions.permissionLevel("notifications")], and in this case it would still be attached to the Notifications interface [Notifications.permissionLevel()].

At the risk of derailing the discussion, I have some concerns about the nature of that spec. Although from an engineering standpoint one could argue for a generic interface, I see two issues. 1) It makes a low-barrier entry to tack on features that require permissions. And 2) it could permit UAs to couple features in a nag sheet, making for a bad user experience. I think it makes sense to keep the permissions mechanism confined to the needs of notifications.

Andrew Wilson wrote:
> 

> One note: if we're going to change the API at all, I'd like to see us change it exactly once - to the draft API defined by the standards body. So I'd be opposed to a transitional phase window.webkitNotifications -> WebKitNotification() -> <draft standard>. Otherwise, applications using this API have to try to support all 3 APIs to deal with legacy browsers.

I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API.



John Gregg wrote:
> Overall my opinion on replaceId is that it's quite useful practically, and we already have real world examples of that usefulness.

> As a real-world example, gmail wants to show two different types of notifications: chat and email. So it uses two replace IDs: _chat_<userid> and _email_<userid>. This ensures that only a single chat notification and a single email notification ever appear for a given user.

Ok, thanks for explaining the reason behind this, and it makes total sense. I agree about the utility of having some kind of ID to coordinate between multiple pages, but I think "replaceId" might be the wrong name here? Maybe just "id" or "globalID"? I think it also gives platforms an opportunity to determine how they want to handle dupe notifications (as you said, ignore or replace).



Andrew Wilson wrote:
> Nit: Can you clarify what "default" means? I think it means "the user has not granted permission yet, but you can still create notifications and they will be queued until such time that the user chooses to grant permission". Maybe something clearer than "default", like "not-granted" (the reason why "default" concerns me is a UA may decide to provide notification permission to all origins as the default configuration, but it seems like this would not map to "default" but rather to "granted".

I understand your concern about ambiguity, but I think your suggestion implies that a default of the opposite policy exists or could exist. And yes, I think any UA that wishes to grant permission by default should just return "granted".

>From a flow perspective, it makes sense for a UA to deny by default, for any web site to detect that it's denied, and then request the UA for permission. Assuming the UA's default policy is the opposite, I don't think the flow fits. That is, assume a UA allows all notifications by default, and the web site detects a default-allowed policy. Do you believe all websites will then ask the user to deny itself the privilege? I think in this scenario, the UA should prompt the user for denial directly, and not assume that the web site will be a good citizen and handle the default-granted case. Therefore, I think UA's that want to give permission by default should just return "granted".

Instead of using passive "granted", "denied", and "default", how about "yes", "no", and "ask"? It's more colloquial, but easier to read, and more actionable.

> 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.
> 
> Just a note, since I'm not sure what "immediately" means - the callback should always be invoked asynchronously even if permissions have already been granted/denied.


I was thinking that in the case where the user already decided, that the callback would be done synchronously, but making it asynchronous would help keep it consistent.



John Gregg wrote:
> 
> I assume permissions might change.  Maybe a user goes into their browser settings and reverts to the default permission.  The app doesn't know this and will continue showing notifications without knowing that these are queued up waiting for permission that hasn't been requested yet.  In the current design there is no ambiguity, because those show() calls will fail informing the app it needs to request permissions.
> 
> Adding the "request-pending" permission state separate from "unknown" (and queueing in the "request-pending" state only) would address that problem and allow for the deferred-show behavior you want.


Andrew Wilson wrote:
> 
> I'm slightly uneasy about queueing notifications - I like the current spec's behavior where notification.show() results in an error event if permission is not granted. Otherwise, if the user changes their permission configuration for an origin (from "granted" to "not-granted") the app would not be notified that its notifications are not being displayed - they would just be silently queued (apps would then have to check permissions themselves before posting every notification if they wanted to detect this case - they couldn't just rely on the error callback).

I had an incomplete understanding of how the notification system works in Chromium, so having show() call onerror() in the request-pending state makes sense.



Adam Barth wrote:
> Unrelated to timeline, it might be worthwhile to make
> createHTMLNotification a runtime-enabled feature so that we can avoid
> offering it to the web at large and possibly restrict it to only a
> whitelisted set of extensions.


I think this is a good idea.

Aaron Boodman wrote:
> Here is a rough plan of how deprecation could work:

I think the year timeline is sensible.

Thanks!
Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120213/af3312fa/attachment.html>