Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On 5 August 2014 16:30, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 5, 2014 at 5:04 PM, Peter Beverloo bever...@google.com wrote: On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren ann...@annevk.nl wrote: Is that available within a service worker? It would be reasonable to expose it, but it currently isn't (afaik). Okay, we'd need to sort that out somehow. Filed https://github.com/slightlyoff/ServiceWorker/issues/421
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Tue, Jul 29, 2014 at 4:28 PM, Peter Beverloo bever...@google.com wrote: When used from a Service Worker, the attribute will implicitly default to the ServiceWorkerRegistration of the running Service Worker. Is that available within a service worker? If serviceWorker is set to null/undefined within a ServiceWorker context, a TypeError will be thrown. I thought the idea was to have it default somehow. It seems to me within a service worker you cannot specify it and you simply always get a notification associated with that service worker. 1. If registration.activeWorker is null, then: 1. Throw a DOMError with name “InvalidStateError” 2. Abort these steps. We could throw a TypeError. (DOMError is not a thing.) Equivalent to what happens when you get the type wrong. Events will be delivered to either the Notification instance, or to the Service Worker, not both. All four events will be exposed to a Service Worker [onnotificationshow, onnotificationclick, onnotificationclose, onnotificationerror]. The events will receive a NotificationEvent which will contain a notification instance. So with each event you get a new instance of the object? I guess that's probably what we want given how getClones() et al work. A bit wasteful, but not too bad. -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 29, 2014 at 4:28 PM, Peter Beverloo bever...@google.com wrote: When used from a Service Worker, the attribute will implicitly default to the ServiceWorkerRegistration of the running Service Worker. Is that available within a service worker? It would be reasonable to expose it, but it currently isn't (afaik). If serviceWorker is set to null/undefined within a ServiceWorker context, a TypeError will be thrown. I thought the idea was to have it default somehow. It seems to me within a service worker you cannot specify it and you simply always get a notification associated with that service worker. Defaulting to the current Service Worker sounds good. One case Jake and I thought of was if/when a Service Worker could get registrations for other SWs in the origin, but that's only a theoretical case today. 1. If registration.activeWorker is null, then: 1. Throw a DOMError with name “InvalidStateError” 2. Abort these steps. We could throw a TypeError. (DOMError is not a thing.) Equivalent to what happens when you get the type wrong. I think it would be nice to be able to distinguish the invalid-value-type case from the no-service-worker case, wouldn't you lose that by throwing TypeErrors in both cases? Events will be delivered to either the Notification instance, or to the Service Worker, not both. All four events will be exposed to a Service Worker [onnotificationshow, onnotificationclick, onnotificationclose, onnotificationerror]. The events will receive a NotificationEvent which will contain a notification instance. So with each event you get a new instance of the object? I guess that's probably what we want given how getClones() et al work. A bit wasteful, but not too bad. I don't think this is a massive problem, in general Notification objects will be very small (depending on the data property, of course). Peter -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Tue, Aug 5, 2014 at 5:04 PM, Peter Beverloo bever...@google.com wrote: On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren ann...@annevk.nl wrote: Is that available within a service worker? It would be reasonable to expose it, but it currently isn't (afaik). Okay, we'd need to sort that out somehow. Defaulting to the current Service Worker sounds good. One case Jake and I thought of was if/when a Service Worker could get registrations for other SWs in the origin, but that's only a theoretical case today. I guess if that becomes available you could override it. That would work. We could throw a TypeError. (DOMError is not a thing.) Equivalent to what happens when you get the type wrong. I think it would be nice to be able to distinguish the invalid-value-type case from the no-service-worker case, wouldn't you lose that by throwing TypeErrors in both cases? It seems like you should just wait for the .ready promise, no? What is a scenario where you'd look at the error and do something different that's not clearly a bug? I filed https://github.com/whatwg/notifications/issues/19 to track this by the way. I got some positive signals from Ehsan at Mozilla. Would be nice to have a few more before we add it, but I guess there's not really that many ways to tackle this. -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
To summarize a discussion we had about this on IRC today:
http://krijnhoetmer.nl/irc-logs/whatwg/20140729#l-509
Jungkee wrote a helpful document for features using Service Workers as well:
https://gist.github.com/jungkees/3154398b8deee7c70139
The |serviceWorker| attribute can be added to the NotificationOptions
dictionary and to the Notification interface, and should be set by the
developer to the ServiceWorkerRegistration instance.
navigator.serviceWorker.ready.then(function(registration) {
new Notification(‘Hello, World!’, {
serviceWorker: registration
});
});
When used from a Service Worker, the attribute will implicitly default to
the ServiceWorkerRegistration of the running Service Worker. If
serviceWorker is set to any non-SWR value, a TypeError will be thrown. If
serviceWorker is set to null/undefined within a ServiceWorker context, a
TypeError will be thrown.
1. If registration.activeWorker is null, then:
1. Throw a DOMError with name “InvalidStateError”
2. Abort these steps.
Events will be delivered to either the Notification instance, or to the
Service Worker, not both. All four events will be exposed to a Service
Worker [onnotificationshow, onnotificationclick, onnotificationclose,
onnotificationerror]. The events will receive a NotificationEvent which
will contain a notification instance.
Thanks,
Peter
On Fri, May 16, 2014 at 3:17 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 16, 2014 at 4:02 PM, Peter Beverloo bever...@google.com
wrote:
On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl
wrote:
Service worker integration makes sense to me. I guess I'll wait with
updating the Notifications API until that is further along.
Do you have a specific milestone in mind?
Probably once it exposes a stable hook for does the current global
have an associated service worker. And if I am to define the service
worker events I suppose some more hooks are needed. Having service
workers in two implementations would also help, as at that point the
stability is a lot less uncertain.
--
http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On 15 May 2014 17:13, Peter Beverloo bever...@google.com wrote: (snip) For |notificationshow|, there is a worry here that if we decide to support delayed notifications, it would enable developers to use notifications to set precise timers: create a delayed notification to be displayed an hour from now, get the |notificationshow| event, and call |notification.close()|. This is something which I'd hope would only be possible through some kind of alarms API, which in itself may be undesirable to start with. Actually, it would probably be fine for delayed notifications to fire a notificationshow event on SWs, as long as script run from the notificationshow event is unable to close the notification (but altering/replacing the notification should be allowed). The protection against developers wasting battery with excessively frequent 'alarms' is then that they won't want to spam users with notifications (or will get their notification permission swiftly revoked if they do). Thanks, Peter
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Thu, May 15, 2014 at 6:12 PM, Peter Beverloo bever...@google.com wrote: For |notificationshow|, there is a worry here that if we decide to support delayed notifications, it would enable developers to use notifications to set precise timers: create a delayed notification to be displayed an hour from now, get the |notificationshow| event, and call |notification.close()|. This is something which I'd hope would only be possible through some kind of alarms API, which in itself may be undesirable to start with. Delayed notifications seems like a new feature of sorts we should probably discuss separately. Although now you can create Notification objects from a service worker you could get them as the result of e.g. a server push so maybe it's not so new as it could be polyfilled in that way... Service worker integration makes sense to me. I guess I'll wait with updating the Notifications API until that is further along. -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 15, 2014 at 6:12 PM, Peter Beverloo bever...@google.com wrote: For |notificationshow|, there is a worry here that if we decide to support delayed notifications, it would enable developers to use notifications to set precise timers: create a delayed notification to be displayed an hour from now, get the |notificationshow| event, and call |notification.close()|. This is something which I'd hope would only be possible through some kind of alarms API, which in itself may be undesirable to start with. Delayed notifications seems like a new feature of sorts we should probably discuss separately. Although now you can create Notification objects from a service worker you could get them as the result of e.g. a server push so maybe it's not so new as it could be polyfilled in that way... Keeping possible future additions in mind allows us to avoid ending up with a precise alarms-like API if and when we decide to do so. Beyond that, the subject of delayed notifications indeed is a separate discussion. Service worker integration makes sense to me. I guess I'll wait with updating the Notifications API until that is further along. Do you have a specific milestone in mind? Thanks, Peter -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Fri, May 16, 2014 at 4:02 PM, Peter Beverloo bever...@google.com wrote: On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl wrote: Service worker integration makes sense to me. I guess I'll wait with updating the Notifications API until that is further along. Do you have a specific milestone in mind? Probably once it exposes a stable hook for does the current global have an associated service worker. And if I am to define the service worker events I suppose some more hooks are needed. Having service workers in two implementations would also help, as at that point the stability is a lot less uncertain. -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
One amendment to (3), which events to expose on the
ServiceWorkerGlobalScope, is that we should only expose the
|notificationclick| and |notificationclose| events.
The benefit of not exposing |notificationerror| is that there are two
situations in which we would fire the event: (a) when there is no service
worker, and (b) when there is no permission. Both are known shortly after
creating the Notification object (but not synchronously). This avoids
confusion about where to listen for errors.
For |notificationshow|, there is a worry here that if we decide to support
delayed notifications, it would enable developers to use notifications to
set precise timers: create a delayed notification to be displayed an hour
from now, get the |notificationshow| event, and call
|notification.close()|. This is something which I'd hope would only be
possible through some kind of alarms API, which in itself may be
undesirable to start with.
Thanks,
Peter
On Tue, May 13, 2014 at 3:33 PM, Peter Beverloo bever...@google.com wrote:
Based on Anne's Reviving Notification Objects thread from last year, I
would like to propose an alternative solution.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-March/251058.html
There are known lifetime issues with Notifications, and rather than tying
them all to the page, how about considering event delivery to a Service
Worker instead? This solves (a) the case in which the tabs are no longer
available, (b) the case where multiple tabs with the launch URL have been
opened, and (c) the case where the user clicks on several notifications
before the page load is complete.
Concretely:
(1) Extend the NotificationOptions interface with a serviceWorker
property. When set to true, event delivery will *only* go to the Service
Worker. However, we should probably still fire |onerror| when no service
worker is current for the page.
(2) Extend the Notification interface with the serviceWorker property,
as a read-only boolean. For browsers which correctly expose properties on
the prototype chain[1], this can therefore be feature-tested using
Notification.prototype.hasOwnProperty('serviceWorker').
(3) Extend the ServiceWorkerGlobalScope interface[2] to define
|notificationactivate| and |notificationshow| events. Both receive a
NotificationEvent object, which exposes a |notification| property providing
access to (a clone of) the relevant notification.
I don't have a strong opinion on whether we should have a
|notificationclose| event in the SW scope. It could be useful for a
background music player, in which dismissing the notification stops
playback (through a postMessage to an open tab, supposedly).
In the future, the NotificationActivateEvent property could be extended to
include information from rich features, e.g. |button|, if we decide to take
that route.
Thanks,
Peter
[1] Chrome bug: http://crbug.com/43394
[whatwg] [Notifications] Persistent notifications depending on Service Workers
Based on Anne's Reviving Notification Objects thread from last year, I
would like to propose an alternative solution.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-March/251058.html
There are known lifetime issues with Notifications, and rather than tying
them all to the page, how about considering event delivery to a Service
Worker instead? This solves (a) the case in which the tabs are no longer
available, (b) the case where multiple tabs with the launch URL have been
opened, and (c) the case where the user clicks on several notifications
before the page load is complete.
Concretely:
(1) Extend the NotificationOptions interface with a serviceWorker
property. When set to true, event delivery will *only* go to the Service
Worker. However, we should probably still fire |onerror| when no service
worker is current for the page.
(2) Extend the Notification interface with the serviceWorker property,
as a read-only boolean. For browsers which correctly expose properties on
the prototype chain[1], this can therefore be feature-tested using
Notification.prototype.hasOwnProperty('serviceWorker').
(3) Extend the ServiceWorkerGlobalScope interface[2] to define
|notificationactivate| and |notificationshow| events. Both receive a
NotificationEvent object, which exposes a |notification| property providing
access to (a clone of) the relevant notification.
I don't have a strong opinion on whether we should have a
|notificationclose| event in the SW scope. It could be useful for a
background music player, in which dismissing the notification stops
playback (through a postMessage to an open tab, supposedly).
In the future, the NotificationActivateEvent property could be extended to
include information from rich features, e.g. |button|, if we decide to take
that route.
Thanks,
Peter
[1] Chrome bug: http://crbug.com/43394
