On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee <[email protected]> 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 > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
