[webkit-dev] Web Notifications API

[Andrew Wilson]

On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee <jonlee at apple.com> wrote:

> 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.
>
>
I don't have an answer for you here, as the internet is vast :) Among
google properties, Gmail and Google Calendar currently use it. I'm not
aware of any other google property that uses it in their web pages, but
some do via extensions.


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

OK, I think we're on the same page here. I don't have a strong opinion one
way or the other regarding the naming of these permission values.


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

Great. That way people don't have to worry about dealing with unexpected
re-entrancy.


>
>
>
> 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/31dc42b7/attachment.html>