[webkit-dev] Web Notifications API

[Andrew Wilson]

On Thu, Feb 9, 2012 at 9:53 AM, Jon Lee <jonlee at apple.com> wrote:

>
> 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?
>

Not sure what you mean - the second notification replaces the first one.


>
> 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?
>

No, so in theory it's possible that you could end up seeing that
notification come in again if one page is significantly delayed behind the
other. In practice, this doesn't seem to be a problem. 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.


>
> 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?
>

Let's imagine the behavior my website wants is:

1) When my page is loaded, if I don't yet have notification permissions
granted, I want to prompt the user.
2) If for some reason I lose notification permissions after the fact, I
would like to re-prompt the user.

With the current API, my app could check permissions on startup, and then
after that never check permissions ever again unless onerror() is fired.
With your proposed change, my app would have to check permissions before
every call to notification.show().

This actually doesn't seem that onerous to me now that I think about it,
and it does provide the developer with a good way to queue up notifications
while waiting for the permission grant to happen, if that's what they want.
So I guess I don't have any objections to this part of your proposal,
assuming I'm not missing some other use case.


>
> Thanks!
> Jon
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120209/0b562847/attachment.html>