- From: Peter Beverloo <beverloo@google.com>
- Date: Fri, 26 Sep 2014 15:36:56 +0100
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Andrew Wilson <atwilson@google.com>
Let me reply to a few points mentioned in this thread -- it's quite overloaded :-). I've also added Andrew, who might know some historical reasons for the events. (Andrew: most of this is in context of persistent notifications.) * Life-time of existing notifications. Chrome currently treats Web Notifications as "persistent" ones. When the page goes away, the notification stays. Interaction with the notification is not going to trigger anything anymore. While I'm in favor of changing this, we have to be very cautious to not break user expectations of existing users of the Web Notification API, for example in calendar applications. * Dropping the close event. I've been wondering myself whether it's valuable to support this. Like Tab, I'm not aware of any messaging application actually using the close event as an indication that the message has been read. There is the "dismiss all" button on most platforms, which definitely does not imply having read the message. It's actually an interesting privacy question as well, for example, if a user dismisses a Facebook notification in their notification center without actually starting the app, should the sender be informed about them having at least looked at their phone? Synchronizing closing of the notification on all the user's devices is an interesting one, but opt-in would be sufficient for this. Given the cost of starting up a Service Worker, I'm interested in exploring opt-in. One potential optimization a UA could do is detect the events bound on a Service Worker's global when it starts, and check whether "notificationclose" is part of this for future invocations. * Dropping the show event. There is one scenario in which Chrome doesn't fire the show event, and that's when no permission has been granted to show notifications (in which case we fire the error event). One theoretical concern with this property is that if we choose to support delayed notifications, it could be used to set precise timers. Depending on how we're going to deal with (asynchronous) errors for persistent notifications, I'm fine with dropping this for them. * Supporting non-persistent notifications in Service Workers. I'd prefer not to, especially if we would auto-close the notifications. There seems to be little point beyond indicating to the user that the Service Worker is running, which feels more like a UA thing if they choose to do so. * Supporting non-persistent notifications in Shared and Dedicated Workers. As long as we continue to support non-persistent notifications, I see no reason not to do this. The globals of both kinds of workers have well defined lifetimes, making the notifications as reliable as in-page ones, most notably on desktop. * Not using the constructor for persistent notifications. There is one more argument to make in favor of creating a promise somewhere, and that's consistency with other Service Worker based APIs. As I understand it, both Web Push and Background Sync are planning to expose their creation methods on the ServiceWorkerRegistration object. If we were to do something analogous, it'd be: navigator.serviceWorker.ready.then(function (registration) { registration.createNotification('Title', { ... }); }); Instead of: navigator.serviceWorker.ready.then(function (registration) { new Notification('Title', { serviceWorker: registration }); }); I have no strong feelings here either, and think it's fine to continue using the constructor with the serviceWorker property set. Both would still use the Notification statics. Having a promise would clean up the error handling a bit, which may occur in the no-permission case. * "Extra-persistent" notifications (non-removable ones) Let's have a separate thread about this. I think it's a loaded subject given that it's incredibly easy to badly annoy the user when using these, and we have to make some careful considerations here. Thanks, Peter On Fri, Sep 26, 2014 at 2:41 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > > None of Twitter, Hangouts, or IRCCloud cares a whit if you close their > > notifications; they still record stuff as unread until you actually > > visit the app. I can't recall any other app I've ever used treating a > > notification closing as a significant event and taking any action, > > either. So, at least based on my immediate testing and long-term > > memory of the notification patterns of the apps I use, I don't think > > there's any use-case for a close event. > > Jake, would be interesting to hear your thoughts on this. If we can > simplify notifications by getting rid of some events I'm all for it. > > > -- > https://annevankesteren.nl/ >
Received on Friday, 26 September 2014 14:37:33 UTC