Re: [whatwg] Notifications and service workers
Jonas Sicking jo...@sicking.cc writes: On Tue, Oct 7, 2014 at 5:42 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Oct 6, 2014 at 9:11 PM, Jonas Sicking jo...@sicking.cc wrote: Though based on Andrew's latest comments, I don't know that anyone strongly feels that we need to keep the event? If you create a non-persistent notification, would you not want to know when the user agent closed it (only relevant if the user agent closes them before the document closes)? If that scenario is not important, we could remove this event too I think. I don't know of a use-case for that. And given that I think we should define that non-persistent notifications go away after a timeout, I think this is the common scenario. The reason I think we should use timeouts is that this matches all OS-native non-persistent notifications that I know of, and also seems like a better UX. I think simple timeouts on anything do not represent good UI. It can be very easy to make non-accessible interfaces using them if a timeout is too short. If you err on the side of caution regarding attention and reading speed that could mean that a timeout becomes largely useless because most users will then dismiss a notification before timeout. Having both an attention deficit and being a fast reader, I am often frustrated with timeout and notification related software issues in multiple ways. For example, I have both experienced not noticing notifications because I was not paying enough attention and being frustrated with notifications opening and closing automatically. Ultimately I see a short timeouts on a notification as an admission that the notification in question is meant to interrupt or at least distract From the current task the user has – if the user does not immediately pay attention, the notification will be gone. this means timeouts do serve as a weak proxy for importance, which people love to lie about. I would probably not use non-persistent notifications myself and hereby urge people to only produce notifications that the user has to clear or none at all. If a notification is not important, just do not use one. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Notifications and service workers
On Wed, Oct 8, 2014 at 7:31 PM, Jonas Sicking jo...@sicking.cc wrote: Interesting. Though if we don't need an event for .close() being called, I suspect we won't need one for a notification being replace. It seems somewhat rare that either of these things would provide significant use to the app if the notification is going away soon anyway. Also, BroadcastChannel was created to allow people to handle these types of things themselves if needed. So we're not leaving people without a workaround if for some reason there is a use case here. Fair. Removed the close event. In https://github.com/slightlyoff/ServiceWorker/issues/505 I'm working out the exact hooks with Jungkee to make the new setup work with service workers. The Notifications API contains a draft of how I think it should work. Perhaps any new review comments from now on should be in a new thread. To keep things somewhat organized. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:06 PM, Jonas Sicking jo...@sicking.cc wrote: I think we should define that non-persistent notifications disappear after a timeout. And define that on mobile platforms with notification centers, that these notifications are *not* added there, but rather is just displayed on screen for a short period of time. Done: https://notifications.spec.whatwg.org/#lifetime-and-ui-integration I also think that we should define that for persistent notifications, that these *are* added to mobile notification centers. Done (same link). I also think that we should define that clicking a non-permanent should as default action focus the window which created the notification. We should also define that during the click event the browser is encouraged to allow calls to window.focus() to, work. Even in UAs which have restrictive policies about when window.focus() is honored. Done: https://notifications.spec.whatwg.org/#activating-a-notification -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote: I don't know of a use-case for that. And given that I think we should define that non-persistent notifications go away after a timeout, I think this is the common scenario. The reason I think we should use timeouts is that this matches all OS-native non-persistent notifications that I know of, and also seems like a better UX. I started to remove the close event and then I noticed we also use it when a notification gets replaced by a newer one. Do we care about that? -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Wed, Oct 8, 2014 at 7:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote: I don't know of a use-case for that. And given that I think we should define that non-persistent notifications go away after a timeout, I think this is the common scenario. The reason I think we should use timeouts is that this matches all OS-native non-persistent notifications that I know of, and also seems like a better UX. I started to remove the close event and then I noticed we also use it when a notification gets replaced by a newer one. Do we care about that? Interesting. Though if we don't need an event for .close() being called, I suspect we won't need one for a notification being replace. It seems somewhat rare that either of these things would provide significant use to the app if the notification is going away soon anyway. Also, BroadcastChannel was created to allow people to handle these types of things themselves if needed. So we're not leaving people without a workaround if for some reason there is a use case here. / Jonas
Re: [whatwg] Notifications and service workers
On Tue, Oct 7, 2014 at 5:42 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Oct 6, 2014 at 9:11 PM, Jonas Sicking jo...@sicking.cc wrote: Though based on Andrew's latest comments, I don't know that anyone strongly feels that we need to keep the event? If you create a non-persistent notification, would you not want to know when the user agent closed it (only relevant if the user agent closes them before the document closes)? If that scenario is not important, we could remove this event too I think. I don't know of a use-case for that. And given that I think we should define that non-persistent notifications go away after a timeout, I think this is the common scenario. The reason I think we should use timeouts is that this matches all OS-native non-persistent notifications that I know of, and also seems like a better UX. / Jonas
Re: [whatwg] Notifications and service workers
On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. I'm not sure that we should pay too much attention to the use case of apps like gmail that want to do lots of hands-on control of their notifications - I think that's pretty much a rare case. I do think it's useful to have some guidelines for how platforms handle notifications, though, just to make sure that some web developer doesn't just test on one platform, and get unexpected behavior on others. So, trying to encourage auto-close behavior (maybe via SHOULD language in the spec) would be good for consistency's sake. Clarifying what should happen when the user clicks on a notification would also be good (should it bring the tab to the foreground? Should it leave it up to the app? Should it provide a default, but allow apps to override it?) - I think all three of these behaviors are currently implemented (or have been in the past) by different UAs.
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson atwil...@google.com wrote: On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. Actually, my question was in regards to the native gmail app. Not web content of any sort. I'm not sure that we should pay too much attention to the use case of apps like gmail that want to do lots of hands-on control of their notifications - I think that's pretty much a rare case. I do think it's useful to have some guidelines for how platforms handle notifications, though, just to make sure that some web developer doesn't just test on one platform, and get unexpected behavior on others. So, trying to encourage auto-close behavior (maybe via SHOULD language in the spec) would be good for consistency's sake. Clarifying what should happen when the user clicks on a notification would also be good (should it bring the tab to the foreground? Should it leave it up to the app? Should it provide a default, but allow apps to override it?) - I think all three of these behaviors are currently implemented (or have been in the past) by different UAs. I agree with this. Generally speaking we tend to leave UI up to browsers and avoid speccing it. However given that notifications is all about UI I think doing so effectively makes the feature untrustable for authors. We don't need to define exact pixels etc, but I think we need to define some semantics in the form of expected behavior of UI. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:15 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson atwil...@google.com wrote: On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. Actually, my question was in regards to the native gmail app. Not web content of any sort. Ah, sorry, didn't understand. From what I can tell, gmail on android aggregates multiple messages into a single notification (like the list notification type you suggested). I'm assuming this is done by gmail itself and not the OS, but my Android-fu is a bit limited so I'm not positive. I note that the native gmail app does different things depending on what type of notification is visible. If there's just one new email in the notification, the notification lets you archive/reply to the email right from the notification, and just clicking the notification brings up the email in the native app. If there are more than one email in the notification (list notification) then there are no extra UI options, and clicking the notification just launches the app and brings up your inbox.
Re: [whatwg] Notifications and service workers
On Oct 1, 2014 4:31 AM, Anne van Kesteren ann...@annevk.nl wrote: Combined with dropping the open event, I think I have enough to rework the current Notifications API. Is there anything I'm missing? I just remembered that another thing that came up was the ability to remove a notification bases on tag. I.e. without having to get a reference to the notification instance. This is probably extra helpful if .get() doesn't return non-persistent notifications. For example to simplify the case when one tab creates a notification, but then the user opens the same app in another tab. The newly opened window might want to close any notifications about pending messages. This could be accomplished using BroadcastChannel, but would be much simpler if we had the ability to close directly using a tag. In fact, the common case when wanting to close a notification is likely one where you know which tag you want to close, but don't have a reference to a Notification instance. / Jonas
Re: [whatwg] Notifications and service workers
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Generally speaking we tend to leave UI up to browsers and avoid speccing it. However given that notifications is all about UI I think doing so effectively makes the feature untrustable for authors. We don't need to define exact pixels etc, but I think we need to define some semantics in the form of expected behavior of UI. I just wanted to pop in and say I agree with this effort. It is exploring new territory, and it's going to be a bit tricky. E.g. can you even write tests for this kind of thing? How specific is this kind of UI-speccing to today's UI patterns, versus those of five years from now? But the overriding point about this being necessary to give authors something worthwhile is very strong.
Re: [whatwg] Notifications and service workers
On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: I agree. One of the big shortcomings of the current spec is that it leaves UI too undefined. This is particularly problematic given that notifications is all about using UI to get certain types of user attention. I'm willing to try making more specific UI recommendations. Have any in mind? -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Sat, Oct 4, 2014 at 4:59 AM, Jonas Sicking jo...@sicking.cc wrote: While JS running in the page can't tell a difference, the user certainly can so it can still be perceived as a breaking change. Yeah, we'll need to see if new Notification() can be changed enough or whether we need three types of notifications... Yeah, it seems like we need to keep this. Through opt-in works. It seems like if we keep this event it should at the very least be possible to tell closed because of user action from closed because of timeout or other platform policy. And maybe also closed because of application calling .close(). Otherwise it doesn't seem like it meets Andrew's use case or the use case above. I added the service worker API now, but have not addressed this particular point yet. Does anyone have a good idea of what should be done here? Note that I don't actually think that we need to even return a Notification instance when a persistent notification is created. Fair, I return undefined now. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: I agree. One of the big shortcomings of the current spec is that it leaves UI too undefined. This is particularly problematic given that notifications is all about using UI to get certain types of user attention. I'm willing to try making more specific UI recommendations. Have any in mind? I think we should define that non-persistent notifications disappear after a timeout. And define that on mobile platforms with notification centers, that these notifications are *not* added there, but rather is just displayed on screen for a short period of time. I also think that we should define that for persistent notifications, that these *are* added to mobile notification centers. I also think that we should define that clicking a non-permanent should as default action focus the window which created the notification. We should also define that during the click event the browser is encouraged to allow calls to window.focus() to, work. Even in UAs which have restrictive policies about when window.focus() is honored. Though some care needs to be taken to not enable pop-unders, but as long as we don't require that UAs honor window.focus() and instead just encourage it, I think that's covered. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:29 AM, Anne van Kesteren ann...@annevk.nl wrote: Yeah, it seems like we need to keep this. Through opt-in works. It seems like if we keep this event it should at the very least be possible to tell closed because of user action from closed because of timeout or other platform policy. And maybe also closed because of application calling .close(). Otherwise it doesn't seem like it meets Andrew's use case or the use case above. I added the service worker API now, but have not addressed this particular point yet. Does anyone have a good idea of what should be done here? If we keep the close event, then I think adding a .reason property to the event object, which can be set to user, platform or api should work. Though based on Andrew's latest comments, I don't know that anyone strongly feels that we need to keep the event? / Jonas
Re: [whatwg] Notifications and service workers
On Sep 30, 2014 1:26 AM, Andrew Wilson atwil...@google.com wrote: In any case it sounds like gmail would not notify properly on platforms where notifications do dissappear after a few seconds, which seems problematic, no? I think that Chrome doesn't generate a close event in the case that the notification is hidden, but agreed, it's a problem. It's frankly one of the major flaws of the original spec that behavior like this isn't well specified, because it really prevents applications from doing anything particularly sophisticated around notification management, because you can't keep notifications on-screen if the notification platform wants to close them, and you can't easily differentiate between user-close and system-close. I agree. One of the big shortcomings of the current spec is that it leaves UI too undefined. This is particularly problematic given that notifications is all about using UI to get certain types of user attention. The fact that platform conventions, and browser conventions, for notifications vary wildly is indeed a big problem. One possible solutions to this is to go really high level and create an API which caters to the lowest common denominator. Another solution is to go super low level and expose lots of API which is describe and expose platform behavior in detail, and then ask application code to write logic to deal with the differences. Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. / Jonas
Re: [whatwg] Notifications and service workers
On Wed, Oct 1, 2014 at 4:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote: * 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. I think from the perspective of the specification this does not change anything. If a platform wants to log all notifications that is fine. What we want to start calling persistent notifications are those for which a service worker will get notified and which can be retrieved using Notification.get(). Hopefully browsers and platforms evolve over time to distinguish the two more clearly. As long as all implementations are willing to change |new Notification| to be non-persistent then that's fine. Note that non-persistent is different from doesn't fire a callback when clicked. While JS running in the page can't tell a difference, the user certainly can so it can still be perceived as a breaking change. * Dropping the close event. Synchronizing closing of the notification on all the user's devices is an interesting one, but opt-in would be sufficient for this. Yeah, it seems like we need to keep this. Through opt-in works. It seems like if we keep this event it should at the very least be possible to tell closed because of user action from closed because of timeout or other platform policy. And maybe also closed because of application calling .close(). Otherwise it doesn't seem like it meets Andrew's use case or the use case above. * Not using the constructor for persistent notifications. 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. It seems nicer to have the association with the registration be implicit by having a method on that object (reg.createNotification()). However, it's very much the factory pattern which is somewhat frowned upon. But hopefully it's not too bad here. Note that I don't actually think that we need to even return a Notification instance when a persistent notification is created. There's no events being fired on such a Notification instance and it doesn't provide any other functionality. It only contains the information that was just passed to the createNotification call. So it wouldn't even be a factory method if we simply don't return a Notification. Combined with dropping the open event, I think I have enough to rework the current Notifications API. Is there anything I'm missing? I think this covers the basic changes needed to enable proper support for persistent vs. non-persistent notifications, which is a big improvement. But I think there's also a lot of additional features that are needed, but that's probably better done separately. Especially since that has less consensus I believe. I'm thinking of things like buttons, progress bars, extra-persistent notifications, control over sound and/or vibration, control over whether it turns on the screen, text input, etc. But at the very least these warrant separate threads. / Jonas
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote: * 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. I think from the perspective of the specification this does not change anything. If a platform wants to log all notifications that is fine. What we want to start calling persistent notifications are those for which a service worker will get notified and which can be retrieved using Notification.get(). Hopefully browsers and platforms evolve over time to distinguish the two more clearly. * Dropping the close event. Synchronizing closing of the notification on all the user's devices is an interesting one, but opt-in would be sufficient for this. Yeah, it seems like we need to keep this. Through opt-in works. * Not using the constructor for persistent notifications. 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. It seems nicer to have the association with the registration be implicit by having a method on that object (reg.createNotification()). However, it's very much the factory pattern which is somewhat frowned upon. But hopefully it's not too bad here. Combined with dropping the open event, I think I have enough to rework the current Notifications API. Is there anything I'm missing? -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Wed, Oct 1, 2014 at 12:31 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote: * 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. I think from the perspective of the specification this does not change anything. If a platform wants to log all notifications that is fine. What we want to start calling persistent notifications are those for which a service worker will get notified and which can be retrieved using Notification.get(). Hopefully browsers and platforms evolve over time to distinguish the two more clearly. * Dropping the close event. Synchronizing closing of the notification on all the user's devices is an interesting one, but opt-in would be sufficient for this. Yeah, it seems like we need to keep this. Through opt-in works. * Not using the constructor for persistent notifications. 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. It seems nicer to have the association with the registration be implicit by having a method on that object (reg.createNotification()). However, it's very much the factory pattern which is somewhat frowned upon. But hopefully it's not too bad here. It could just be an accessor on the ServiceWorkerRegistration for both convenience and consistency, mapping to the constructor with the serviceWorker property set. We'll need to keep the constructor in either case. Combined with dropping the open event, I think I have enough to rework the current Notifications API. Is there anything I'm missing? One argument I came across for overloading requestPermission is the following: Promise.all([ Notification.requestPermission(), swRegistration.push.requestPermission() ]).then(...); Might be worth considering, it's relatively cheap to support and can be implemented without breaking backwards compatibility. Thanks, Peter -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com wrote: OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). Ah, so the fact that the user close one notification is seen as an indicator that the user doesn't want more notifications right now. This definitely seems like the best use case for the close event so far. Though it doesn't seem like you'd actually want a service worker, or indeed the full app, to be started up in order to handle that event. For an app that wants to do something like this, but the app uses persistent notifications, I think using Notification.get() is the best solution. This way the application can catch closing of notifications whenever they happen, but the app still doesn't need to be woken up if it's not running when a notification is closed. For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. Interesting. Yeah, Notification.get() seems like it would help you solve this. Though potentially the API should also have a function like Notification.close(DOMString tag). Seems like a common use case of wanting to close a notification when the user engages with a piece of UI, and it seems silly to have to instantiate a Notification instance through .get() to do so. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. Yeah, this is the case that Jake brought up. Though Tab pointed out that other chat systems generally does not treat close as an hint for user has read. Interesting to hear that gmail does. On what platforms do non-persistent notifications not close after a timeout? My test on mac and linux chrome just showed that notifications never close on those platforms.
Re: [whatwg] Notifications and service workers
On Sep 30, 2014 12:48 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com wrote: OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). Ah, so the fact that the user close one notification is seen as an indicator that the user doesn't want more notifications right now. This definitely seems like the best use case for the close event so far. Though it doesn't seem like you'd actually want a service worker, or indeed the full app, to be started up in order to handle that event. For an app that wants to do something like this, but the app uses persistent notifications, I think using Notification.get() is the best solution. This way the application can catch closing of notifications whenever they happen, but the app still doesn't need to be woken up if it's not running when a notification is closed. For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. Interesting. Yeah, Notification.get() seems like it would help you solve this. Though potentially the API should also have a function like Notification.close(DOMString tag). Seems like a common use case of wanting to close a notification when the user engages with a piece of UI, and it seems silly to have to instantiate a Notification instance through .get() to do so. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. Yeah, this is the case that Jake brought up. Though Tab pointed out that other chat systems generally does not treat close as an hint for user has read. Interesting to hear that gmail does. On what platforms do non-persistent notifications not close after a timeout? My test on mac and linux chrome just showed that notifications never close on those platforms. I guess I don't know enough about the ins and outs of osx notifications. But all my other osx apps remove notifications after a few seconds. But it is of course chrome's choice what UI to display. In any case it sounds like gmail would not notify properly on platforms where notifications do dissappear after a few seconds, which seems problematic, no? / Jonas
Re: [whatwg] Notifications and service workers
On Tue, Sep 30, 2014 at 10:15 AM, Jonas Sicking jo...@sicking.cc wrote: On Sep 30, 2014 12:48 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com wrote: OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). Ah, so the fact that the user close one notification is seen as an indicator that the user doesn't want more notifications right now. This definitely seems like the best use case for the close event so far. Though it doesn't seem like you'd actually want a service worker, or indeed the full app, to be started up in order to handle that event. For an app that wants to do something like this, but the app uses persistent notifications, I think using Notification.get() is the best solution. This way the application can catch closing of notifications whenever they happen, but the app still doesn't need to be woken up if it's not running when a notification is closed. For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. Interesting. Yeah, Notification.get() seems like it would help you solve this. Though potentially the API should also have a function like Notification.close(DOMString tag). Seems like a common use case of wanting to close a notification when the user engages with a piece of UI, and it seems silly to have to instantiate a Notification instance through .get() to do so. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. Yeah, this is the case that Jake brought up. Though Tab pointed out that other chat systems generally does not treat close as an hint for user has read. Interesting to hear that gmail does. On what platforms do non-persistent notifications not close after a timeout? My test on mac and linux chrome just showed that notifications never close on those platforms. I guess I don't know enough about the ins and outs of osx notifications. But all my other osx apps remove notifications after a few seconds. But it is of course chrome's choice what UI to display. Chrome on OSX isn't using the native notification framework (at least, not on my laptop). In any case it sounds like gmail would not notify properly on platforms where notifications do dissappear after a few seconds, which seems problematic, no? I think that Chrome doesn't generate a close event in the case that the notification is hidden, but agreed, it's a problem. It's frankly one of the major flaws of the original spec that behavior like this isn't well specified, because it really prevents applications from doing anything particularly sophisticated around notification management, because you can't keep notifications on-screen if the notification platform wants to close them, and you can't easily differentiate between user-close and system-close. The thing to remember is that gmail's notification functionality was written back when Chrome was the only browser that supported notifications, and there were no system notification platforms (at least, none that were used by any UAs). So some of the behavior in Gmail only makes sense on platforms where Chrome's original notification
Re: [whatwg] Notifications and service workers
Apologies if I miss some subtleties in the preceding discussion - I've
scanned the thread, but I haven't been following closely.
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote:
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.
I suspect it's OK to change this, especially since (for Chrome, at least)
most platforms are moving to a model where notifications don't stay on the
screen anyway (they move to a notification center). That said, I've never
really understood the interest in auto-closing notifications, since if a
web page wants to close its notifications, it's trivial to do so in an
onclose handler - I guess the issue might be notifications coming from a
worker, where the worker doesn't get notified that it's going away? Maybe
the right fix is that workers should get a close event also :)
In any case, agreed with Jonas that if we're going to build non-persistent
notifications, then perhaps they should have a fixed time limit (possibly
UA-adjustable) and not be tied explicitly to a source's lifetime.
* 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?
Gmail tracks information internally about all open notifications so it
knows what chat window, email, etc to display when the user clicks on one.
It cleans up those data structures as notifications are closed, so if we
stop generating close events, then gmail will leak even more memory than it
currently does :)
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.
I'm not aware of any particular use cases here. Gmail isn't listening to
show events, AFAICT.
* 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
Re: [whatwg] Notifications and service workers
On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com wrote: * 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? Gmail tracks information internally about all open notifications so it knows what chat window, email, etc to display when the user clicks on one. It cleans up those data structures as notifications are closed, so if we stop generating close events, then gmail will leak even more memory than it currently does :) Could this be solved by using the 'data' attribute when creating a Notification? / Jonas
Re: [whatwg] Notifications and service workers
Sounds exactly like an use case of the 'data' attribute. 2014-09-29 12:23 GMT+03:00 Jonas Sicking jo...@sicking.cc: On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com wrote: * 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? Gmail tracks information internally about all open notifications so it knows what chat window, email, etc to display when the user clicks on one. It cleans up those data structures as notifications are closed, so if we stop generating close events, then gmail will leak even more memory than it currently does :) Could this be solved by using the 'data' attribute when creating a Notification? / Jonas
Re: [whatwg] Notifications and service workers
That only works if 'data' is a structured-cloneable data structure. I mean, typically in a full-featured web app, you have a large, complex data structure and you typically want to keep references into that data structure - you can't typically just copy pieces out and expect to perform operations on them. On Mon, Sep 29, 2014 at 11:54 AM, Robert Bîndar robertbin...@gmail.com wrote: Sounds exactly like an use case of the 'data' attribute. 2014-09-29 12:23 GMT+03:00 Jonas Sicking jo...@sicking.cc: On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com wrote: * 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? Gmail tracks information internally about all open notifications so it knows what chat window, email, etc to display when the user clicks on one. It cleans up those data structures as notifications are closed, so if we stop generating close events, then gmail will leak even more memory than it currently does :) Could this be solved by using the 'data' attribute when creating a Notification? / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 3:10 AM, Andrew Wilson atwil...@google.com wrote: That only works if 'data' is a structured-cloneable data structure. Per spec it is yes. / Jonas
Re: [whatwg] Notifications and service workers
I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. -atw On Mon, Sep 29, 2014 at 12:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 3:10 AM, Andrew Wilson atwil...@google.com wrote: That only works if 'data' is a structured-cloneable data structure. Per spec it is yes. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. But if the data that you want to associate with the notification isn't structured clonable, how are you going to make that data survive a page reload? Keep in mind that for persistent notifications, the notification often outlives the page that created the notification. It might help to have some concrete examples of what you're trying to do here. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. But if the data that you want to associate with the notification isn't structured clonable, how are you going to make that data survive a page reload? Keep in mind that for persistent notifications, the notification often outlives the page that created the notification. OK, I get it - we're talking about different models. I'm talking about the current Gmail use case, where I don't want notifications to live forever (in fact, I close them all when you close the main Gmail pane). I understand that for persistent notifications, the uses are different. And again, apologies if I missed the context and the idea was to only remove the close event for persistent notifications - it's the danger of dropping into the middle of a thread :) Hopefully the plan is to continue enabling web properties that want to go the Gmail route to continue doing so, and for those pages, I think a 'close' event is useful. I think we're talking about both. But I wanted to point out that the code flow you were talking about didn't seem to work for persistent notifications. I'd rather keep persistent and non-persistent notifications as similar as possible. Though as possible being key. I.e. I think it's ok for them to be different when that makes sense. I still don't understand the use case you are talking about though. Could you perhaps provide an example of the features that gmail is building and which needs these non-clonable data structures? / Jonas
Re: [whatwg] Notifications and service workers
OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. On Mon, Sep 29, 2014 at 2:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. But if the data that you want to associate with the notification isn't structured clonable, how are you going to make that data survive a page reload? Keep in mind that for persistent notifications, the notification often outlives the page that created the notification. OK, I get it - we're talking about different models. I'm talking about the current Gmail use case, where I don't want notifications to live forever (in fact, I close them all when you close the main Gmail pane). I understand that for persistent notifications, the uses are different. And again, apologies if I missed the context and the idea was to only remove the close event for persistent notifications - it's the danger of dropping into the middle of a thread :) Hopefully the plan is to continue enabling web properties that want to go the Gmail route to continue doing so, and for those pages, I think a 'close' event is useful. I think we're talking about both. But I wanted to point out that the code flow you were talking about didn't seem to work for persistent notifications. I'd rather keep persistent and non-persistent notifications as similar as possible. Though as possible being key. I.e. I think it's ok for them to be different when that makes sense. I still don't understand the use case you are talking about though. Could you perhaps provide an example of the features that gmail is building and which needs these non-clonable data structures? / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com wrote: OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). Ah, so the fact that the user close one notification is seen as an indicator that the user doesn't want more notifications right now. This definitely seems like the best use case for the close event so far. Though it doesn't seem like you'd actually want a service worker, or indeed the full app, to be started up in order to handle that event. For an app that wants to do something like this, but the app uses persistent notifications, I think using Notification.get() is the best solution. This way the application can catch closing of notifications whenever they happen, but the app still doesn't need to be woken up if it's not running when a notification is closed. For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. Interesting. Yeah, Notification.get() seems like it would help you solve this. Though potentially the API should also have a function like Notification.close(DOMString tag). Seems like a common use case of wanting to close a notification when the user engages with a piece of UI, and it seems silly to have to instantiate a Notification instance through .get() to do so. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. Yeah, this is the case that Jake brought up. Though Tab pointed out that other chat systems generally does not treat close as an hint for user has read. Interesting to hear that gmail does. On what platforms do non-persistent notifications not close after a timeout? / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. Based on your emails later in this thread, it sounds like gmail might not be relying on being able to associate non-structured-clonable data with non-persistent Notifications. However I realized this morning that this actually is doable. You can simply set expando properties, or use a WeakMap, to associate arbitrary data with a Notification object instance. So in case it's needed, or just beneficial, this is actually doable. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 12:14 PM, Jonas Sicking jo...@sicking.cc wrote: For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. Actually, I just realized that perhaps neither of these would work. We've elsewhere in this thread talked about restricting Notification.get() to only return persistent notifications. And I think that on at least some platforms, possibly even most, non-persistent notifications are closed after a timeout. So the close event wouldn't indicate any user intent there. / Jonas
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
Or, should persistent notifications not use a constructor at all?
What's the purpose of having a reference to a Notification object if
no events will ever fire on it? Maybe we should have a function like
promise = createPersistentNotification(...);
promise.then(notificationWasShown, notificationWasRejected);
Well presumably we still want to share an object of sorts as part of
the event, so all the notification data is exposed somehow. A promise
does not make much sense to me as a service worker can be killed at
any point. new Notification(..., {serviceWorker:...}) still makes
the most sense. You create a new notification and by assocation with a
service worker you extend its lifetime.
If we tie non-persistent notifications to the lifetime of a global,
then I don't know that it makes sense to allow them to be created from
a worker.
Dedicated workers are tied to the lifetime of a global. And shared
workers are tied to the lifetime of the union of their associated
globals. The point is mostly that they will be removed from the
notification center at some point.
--
https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: Or, should persistent notifications not use a constructor at all? What's the purpose of having a reference to a Notification object if no events will ever fire on it? Maybe we should have a function like promise = createPersistentNotification(...); promise.then(notificationWasShown, notificationWasRejected); Well presumably we still want to share an object of sorts as part of the event, so all the notification data is exposed somehow. A promise does not make much sense to me as a service worker can be killed at any point. I'm not sure I understand what you are saying here. The above code is the creation steps, not the notification steps. I agree that the click event needs to expose the Notification object. But the SW click event needs to be fired at the SW global, and have as one of its properties the Notification object. Exactly because the SW might have been killed previously and is just getting spawned in order to fire the click event. Thus no other references to the Notification object might exist. / Jonas
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: promise = createPersistentNotification(...); promise.then(notificationWasShown, notificationWasRejected); Well presumably we still want to share an object of sorts as part of the event, so all the notification data is exposed somehow. A promise does not make much sense to me as a service worker can be killed at any point. I'm not sure I understand what you are saying here. The above code is the creation steps, not the notification steps. Oh, but shown implies it's displayed, which currently can happen later. But as per the other thread maybe we should get rid of that. Assuming we get rid of that, this seems to help a bit with error handling, but is otherwise mostly identical in approach to just keeping the constructor. I agree that the click event needs to expose the Notification object. But the SW click event needs to be fired at the SW global, and have as one of its properties the Notification object. Exactly because the SW might have been killed previously and is just getting spawned in order to fire the click event. Thus no other references to the Notification object might exist. Sure. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. jackalm...@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/
Re: [whatwg] Notifications and service workers
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 ann...@annevk.nl wrote:
On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. jackalm...@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/
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 6:40 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: promise = createPersistentNotification(...); promise.then(notificationWasShown, notificationWasRejected); Well presumably we still want to share an object of sorts as part of the event, so all the notification data is exposed somehow. A promise does not make much sense to me as a service worker can be killed at any point. I'm not sure I understand what you are saying here. The above code is the creation steps, not the notification steps. Oh, but shown implies it's displayed, which currently can happen later. But as per the other thread maybe we should get rid of that. Assuming we get rid of that, this seems to help a bit with error handling, but is otherwise mostly identical in approach to just keeping the constructor. It's a good point that if the above call happens in a SW, then there's no guarantee that it'll receive either of those callbacks. So it comes down to if we need show, and I guess error, events. One option that I could think of is that Windows that create a notification could detect if the notification fails to be displayed, and if so display in-page UI. Either to replace the notification, or to indicate to the user that notifications currently don't work. In this case the above API could work since a SW can't display such UI anyway, and so it doesn't matter that it might not receive the promise callbacks. / Jonas
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 7:36 AM, Peter Beverloo bever...@google.com wrote: 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. The current situation feels pretty broken in that the API was designed for, and only really works for, non-persistent notifications, however all implementations implement persistent notifications, presumably because that's what the most urgent need was. I think we might need some form of transition period to transition to whatever API we decide is the right one. * 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. Ah, that's the best use case I've heard so far. Though, do you really want to close a given notification on all devices just because the user pressed clear all on one device? Or is it better to close the notification on all devices once the user engages with the relevant part of the app, for example by clicking the notification. 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. Yeah. Though I think interest in did this notification close will vary with notification. Which means that if you are interested in close events for one type of notifications in your app, suddenly you pay the price for all of 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. The main use case I can think of is if we enable playing audio from a SW, in which case you might want to notify about change in songs. But I'm fine with leaving this unsupported for now. As long as whatever syntax we use doesn't preclude it from being added later should the need arise. * 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. I'm a bit skeptical about tying even non-persistent notifications to the lifetime of a global of any sort. Either window or worker. If the use case of non-persistent notifications is to give background apps some temporary screen real estate where they can inform the user about a change, then shouldn't that generally disappear after a short timeout? I believe (but am not sure) that Android and iOS have the concept of non-persistent notifications that are displayed at the top of the screen for a few seconds. These do not go into the notification center. OSX is somewhat different in that it displays an on-screen non-persistent notification. But it also adds the notification to a notification center. Though this notification center is more of a log than stuff that happened since you last looked at your device. I.e. stuff on this list doesn't go away when you click it, and applications don't remove items from here when you interact with the app. Most importantly, I don't know of any types of notifications on any platform that go away when you close the app. While I agree that we generally should leave UI up to UAs, we need to have some model of what type of interaction authors can expect when using various APIs. Leaving UI too undefined is part of what has gotten us into the current somewhat messy state (though the lack of SW certainly didn't help). So all that said, I'm fine with allowing
Re: [whatwg] Notifications and service workers
On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren ann...@annevk.nl wrote: Strawman: We classify existing notifications as non-persistent notifications. Only notifications associated with a service worker are persistent. This is a little bit implicit for my taste. But I don't feel very strongly. I think it makes a lot of sense if we require service workers for persistent notifications. I figured we could rename the field from serviceWorker to something more explicit, but I can't really think of a good name. That means we should tie normal non-persistent notifications to the lifetime of the global. I take it we still want to allow those within workers, right? But maybe they are rare enough that by default we only fire click events. For persistent notifications we fire them at the SW, for non-persistent at the Notification object. If we in the future find actual use cases for close/show we can add ways to opt in to receiving those. And if we find use cases for *not* receiving click (in particular to SW) we can add ways to opt out of those. This strategy makes sense to me. If Jake and Peter (and everyone else who feels inclined :-)) could comment on this revised proposal that'd be great. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On 24 September 2014 01:21, Jonas Sicking jo...@sicking.cc wrote: * Notifications that close when a page goes away does not seem useful on mobile, but could be useful on desktop to enable minimized applications, or applications whose window is covered by other windows, call attention to themselves. I agree with Tab regarding track change. But more than that, we shouldn't be making a platform distinction here, that may not hold true in a few years. * For persistent notifications, in cases where the application cares about the user clicking on the notification (as opposed to fire-and-forget notifications), we should always send a notification to the service worker. In this scenario it never seems useful to fire an event on the Notification instance since that will just mean multiple codepaths trying to handle the same click. At best that would be wasted performance, at worst it could mean broken UI or application logic. Totally agree, I didn't realise this was possible in the original proposal. The option that makes it a persistent notification should retarget all events to the serviceworker. If the serviceworker is invalid, I guess we throw? * I'm uncertain about if non-persistent notifications are important enough to target at this point. But I'm heavily biased from having worked mainly on mobile web lately. Not sure what you mean here. Aren't non-persistent notifications fully shipped and supported? * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? Yeah: * User gets new chat message * Push message * Notification * User reads chat message but doesn't need to respond, dismisses notification * Close event * Message sent to the server to make message as read * Notifications auto-dismissed on other devices the user has On 25 September 2014 11:02, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren ann...@annevk.nl wrote: Strawman: We classify existing notifications as non-persistent notifications. Only notifications associated with a service worker are persistent. This is a little bit implicit for my taste. But I don't feel very strongly. I think it makes a lot of sense if we require service workers for persistent notifications. I figured we could rename the field from serviceWorker to something more explicit, but I can't really think of a good name. eventTarget: serviceWorkerRegistration persistWith: serviceWorkerRegistration That means we should tie normal non-persistent notifications to the lifetime of the global. I take it we still want to allow those within workers, right? The ServiceWorker default would be persistent though right? Creating a non-persistant notification in a ServiceWorker is likely to go wrong as you lose your event handers when the worker terminates. But maybe they are rare enough that by default we only fire click events. For persistent notifications we fire them at the SW, for non-persistent at the Notification object. If we in the future find actual use cases for close/show we can add ways to opt in to receiving those. And if we find use cases for *not* receiving click (in particular to SW) we can add ways to opt out of those. This strategy makes sense to me. If Jake and Peter (and everyone else who feels inclined :-)) could comment on this revised proposal that'd be great. I don't have a use-case for show right now, but I think we need to keep close for the use-case above. An events property could take an array to restrict the events a notification will fire (defaulting to all).
Re: [whatwg] Notifications and service workers
On Thu, Sep 25, 2014 at 12:25 PM, Jake Archibald jaffathec...@gmail.com wrote: Totally agree, I didn't realise this was possible in the original proposal. The option that makes it a persistent notification should retarget all events to the serviceworker. If the serviceworker is invalid, I guess we throw? Yup. eventTarget: serviceWorkerRegistration persistWith: serviceWorkerRegistration Hmm, serviceWorker still seems best. The ServiceWorker default would be persistent though right? Creating a non-persistant notification in a ServiceWorker is likely to go wrong as you lose your event handers when the worker terminates. Yeah, for service workers the default would be a persistent one. I was thinking we could allow an explicit serviceWorker: null to override that, but I'm not sure it buys us much. The lifetime of non-persistent notifications would be the lifetime of the global they are created in (or presumably lifetime of the active document in case of a document environment). I don't have a use-case for show right now, but I think we need to keep close for the use-case above. An events property could take an array to restrict the events a notification will fire (defaulting to all). That would work too. Not sure I have a good sense of what would be best here. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Thu, Sep 25, 2014 at 3:02 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
Strawman: We classify existing notifications as non-persistent
notifications. Only notifications associated with a service worker are
persistent.
This is a little bit implicit for my taste. But I don't feel very strongly.
I think it makes a lot of sense if we require service workers for
persistent notifications. I figured we could rename the field from
serviceWorker to something more explicit, but I can't really think of
a good name.
I was thinking of something more along the lines of using different
constructors for persistent vs. non-persistent notifications. But like
I said, I don't feel strongly.
Or, should persistent notifications not use a constructor at all?
What's the purpose of having a reference to a Notification object if
no events will ever fire on it? Maybe we should have a function like
promise = createPersistentNotification(...);
promise.then(notificationWasShown, notificationWasRejected);
That means we should tie normal non-persistent notifications to the
lifetime of the global. I take it we still want to allow those within
workers, right?
If we tie non-persistent notifications to the lifetime of a global,
then I don't know that it makes sense to allow them to be created from
a worker.
But maybe a better model is to define that non-persistent
notifications are shown for a small period of time. That's how they
seem to be implemented on existing OSs. OSX shows notifications for a
few seconds, then they go away.
But maybe they are rare enough that by default we only fire click
events. For persistent notifications we fire them at the SW, for
non-persistent at the Notification object.
If we in the future find actual use cases for close/show we can
add ways to opt in to receiving those. And if we find use cases for
*not* receiving click (in particular to SW) we can add ways to opt
out of those.
This strategy makes sense to me. If Jake and Peter (and everyone else
who feels inclined :-)) could comment on this revised proposal that'd
be great.
Having thought about this some more, I think it would create a very
messy API if we end up with
new Notification(Hello world, {
body: ...,
dontFireClick: true,
requestExtraEvents: [show, close]
});
Generally speaking, starting a SW is a fairly expensive operation. So
I think it's good if APIs that hook into SW allow the author to be
explicit about what events they care about receiving.
OTOH, if we really can't think of any use cases for show/close events,
then it seems silly to require that every single caller specifies that
it wants to receive click and nothing else.
/ Jonas
Re: [whatwg] Notifications and service workers
On Thu, Sep 25, 2014 at 3:25 AM, Jake Archibald jaffathec...@gmail.com wrote: On 24 September 2014 01:21, Jonas Sicking jo...@sicking.cc wrote: * Notifications that close when a page goes away does not seem useful on mobile, but could be useful on desktop to enable minimized applications, or applications whose window is covered by other windows, call attention to themselves. I agree with Tab regarding track change. But more than that, we shouldn't be making a platform distinction here, that may not hold true in a few years. Agreed. * I'm uncertain about if non-persistent notifications are important enough to target at this point. But I'm heavily biased from having worked mainly on mobile web lately. Not sure what you mean here. Aren't non-persistent notifications fully shipped and supported? Do implementations really treat them as non-persistent? In FirefoxOS we treat them as persistent. In Firefox for Android we put them in the Android notification tray, where generally only persistent notifications go I thought. And indeed we don't have any code to automatically remove them. But I don't know what other implementations do? * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? Yeah: * User gets new chat message * Push message * Notification * User reads chat message but doesn't need to respond, dismisses notification * Close event * Message sent to the server to make message as read * Notifications auto-dismissed on other devices the user has Hmm.. is close really a decent proxy for read? I personally often read notifications without clearing them, since I read the temporary on-screen notification. And on occasion when my notification tray overflow, I clear notifications without reading them. But I hate using my own usage patterns in design. Do we have any data on what native applications do with similar callbacks? Assuming they exist in other notification platforms... But maybe they are rare enough that by default we only fire click events. For persistent notifications we fire them at the SW, for non-persistent at the Notification object. If we in the future find actual use cases for close/show we can add ways to opt in to receiving those. And if we find use cases for *not* receiving click (in particular to SW) we can add ways to opt out of those. This strategy makes sense to me. If Jake and Peter (and everyone else who feels inclined :-)) could comment on this revised proposal that'd be great. I don't have a use-case for show right now, but I think we need to keep close for the use-case above. An events property could take an array to restrict the events a notification will fire (defaulting to all). I'd really not want to use all as a default. That will result in us starting service workers much more often than we need, which at best is a battery drain, at worst is a performance issue. / Jonas
Re: [whatwg] Notifications and service workers
On Thu, Sep 25, 2014 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote: * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? Yeah: * User gets new chat message * Push message * Notification * User reads chat message but doesn't need to respond, dismisses notification * Close event * Message sent to the server to make message as read * Notifications auto-dismissed on other devices the user has Hmm.. is close really a decent proxy for read? I personally often read notifications without clearing them, since I read the temporary on-screen notification. And on occasion when my notification tray overflow, I clear notifications without reading them. But I hate using my own usage patterns in design. Do we have any data on what native applications do with similar callbacks? Assuming they exist in other notification platforms... The use-case presented by Jake seems precisely opposite what actually happens today in multiple apps, as I alluded to in my previous email: * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? I'm also not sure, on first thought, how an app would respond to a close event. I don't think that apps on Android currently care if you close a notification? At least, nothing that I use seems to do anything about it; IRCCloud, for example, doesn't mark mentions as already read if I close the mention notification. Some use-cases would be useful. 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. The one example I can think of that's kinda like this is the Google Maps Navigation Notification. It actively resists being closed, for one thing, but it does have a Dismiss button on itself (because it's a Rich Notification or whatever), which when pressed also cancels navigation in the app. This seems like a specialized function of the app itself, using some future form of rich notifications, though, and not something we can or should generalize to other apps. It's definitely not an example we should generalize to generic clearing out all my notifications behaviors, because it explicitly resists such things and requires an affirmative and purposeful action on the part of the user to dismiss it. ~TJ
Re: [whatwg] Notifications and service workers
On Thu, Sep 25, 2014 at 4:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: The one example I can think of that's kinda like this is the Google Maps Navigation Notification. It actively resists being closed, for one thing, but it does have a Dismiss button on itself (because it's a Rich Notification or whatever), which when pressed also cancels navigation in the app. This seems like a specialized function of the app itself, using some future form of rich notifications, though, and not something we can or should generalize to other apps. It's definitely not an example we should generalize to generic clearing out all my notifications behaviors, because it explicitly resists such things and requires an affirmative and purposeful action on the part of the user to dismiss it. FWIW, I think there is a need for extra persistent notifications. Which I think mainly mean that they don't get removed if the user presses the clear all button in a notification tray. Or that the notification wouldn't go away when simply clicked. This type of notification can be useful for ongoing activities. Such as navigational apps, or download progress. API-wise this could be supported by simply adding an additional flag to NotificationOptions, like resistClear: true or noclear: true. This flag would be ignored for non-persistent notifications. It might still be good for UAs to allow removing this type of notification, but I think if and how to enable that is a UA decision. / Jonas
Re: [whatwg] Notifications and service workers
On Wed, Sep 24, 2014 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: * We should consider the case of persistent notifications separate from notifications that automatically close when a page goes away. Strawman: We classify existing notifications as non-persistent notifications. Only notifications associated with a service worker are persistent. That would also allow us to remove the complexity of exposing a single non-persistent notification as multiple Notification objects. * Right now the spec requires that whenever a user interacts with a persistent notification, the application that created the notification is immediately started so that we can send the appropriate click/close/future-button-press event to it's service worker. This can be quite expensive. At the very least applications need to be able to indicate that they don't need to be told about the close event. * Even better would likely be content could indicate which events they want fired at the service worker when creating a Notification. Other events would be dropped. This list vary by-notification, not by-app. * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? Is this only about the close event? We could opt not to support for persistent notifications as a start if we follow my strawman above. I'm not a 100% sure why it's there either at this point. I suspect not supporting it would not necessarily break anything. Probably mostly there for symmetry with the close() method. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Sep 24, 2014 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: * We should consider the case of persistent notifications separate from notifications that automatically close when a page goes away. Strawman: We classify existing notifications as non-persistent notifications. Only notifications associated with a service worker are persistent. This is a little bit implicit for my taste. But I don't feel very strongly. That would also allow us to remove the complexity of exposing a single non-persistent notification as multiple Notification objects. Yeah, no matter what syntax we use for creating persistent/non-persistent notifications, I agree that .get() should only return persistent notifications. * Right now the spec requires that whenever a user interacts with a persistent notification, the application that created the notification is immediately started so that we can send the appropriate click/close/future-button-press event to it's service worker. This can be quite expensive. At the very least applications need to be able to indicate that they don't need to be told about the close event. * Even better would likely be content could indicate which events they want fired at the service worker when creating a Notification. Other events would be dropped. This list vary by-notification, not by-app. * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? Is this only about the close event? We could opt not to support for persistent notifications as a start if we follow my strawman above. I'm not a 100% sure why it's there either at this point. I suspect not supporting it would not necessarily break anything. Probably mostly there for symmetry with the close() method. Actually, it might also be the show event. But see also my sub-thread with Tab. It *might* be useful to not receive a click event for persistent notifications. I don't know of any use cases, but my gut feeling is that they are there. But maybe they are rare enough that by default we only fire click events. For persistent notifications we fire them at the SW, for non-persistent at the Notification object. If we in the future find actual use cases for close/show we can add ways to opt in to receiving those. And if we find use cases for *not* receiving click (in particular to SW) we can add ways to opt out of those. / Jonas
[whatwg] Notifications and service workers
Peter and Jake made a proposal for notifications and service workers, but I believe Jonas wanted something without events. I'll outline the proposal from Peter and Jake below. Hopefully we can then discuss on how to move this forward. We add serviceWorker to Notification and NotificationOptions. When a Notification is constructed within a service worker it is set automatically, in other environments it needs to be set to a ServiceWorkerRegistration object (allowing it to be overridden inside a service worker is probably okay). (If there's an issue with the ServiceWorkerRegistration object we throw.) If this succeeds, the underlying notification is associated with a service worker. If a notification is associated with a service worker, events are dispatched to the service worker, rather than to Notification objects associated with the notification. These events also expose a new Notification object (cloning is cheap). Suggestions I remember: * Expose promises on Notification objects to see whether a notification has been clicked or closed. (And keep track of such state somewhere.) * Dispatch events to Notification objects as well even if the notification has an associated service worker. Requiring message channel roundtrips for this is cumbersome. This is also tracked on GitHub: https://github.com/whatwg/notifications/issues/19 -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
After having talked to our web developers, and having talked to Olli, I've come to the following conclusions: * We should consider the case of persistent notifications separate from notifications that automatically close when a page goes away. * Notifications that close when a page goes away does not seem useful on mobile, but could be useful on desktop to enable minimized applications, or applications whose window is covered by other windows, call attention to themselves. * Persistent vs. non-persistent doesn't seem like a platform difference, but rather two different types of notifications that content could want to create. * For persistent notifications, in cases where the application cares about the user clicking on the notification (as opposed to fire-and-forget notifications), we should always send a notification to the service worker. In this scenario it never seems useful to fire an event on the Notification instance since that will just mean multiple codepaths trying to handle the same click. At best that would be wasted performance, at worst it could mean broken UI or application logic. * Same applies to close in addition to click. * For non-persistent notifications, it seems good to not require that a service worker is used. * I'm uncertain about if non-persistent notifications are important enough to target at this point. But I'm heavily biased from having worked mainly on mobile web lately. * Right now the spec requires that whenever a user interacts with a persistent notification, the application that created the notification is immediately started so that we can send the appropriate click/close/future-button-press event to it's service worker. This can be quite expensive. At the very least applications need to be able to indicate that they don't need to be told about the close event. * Even better would likely be content could indicate which events they want fired at the service worker when creating a Notification. Other events would be dropped. This list vary by-notification, not by-app. * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? / Jonas On Tue, Sep 23, 2014 at 6:31 AM, Anne van Kesteren ann...@annevk.nl wrote: Peter and Jake made a proposal for notifications and service workers, but I believe Jonas wanted something without events. I'll outline the proposal from Peter and Jake below. Hopefully we can then discuss on how to move this forward. We add serviceWorker to Notification and NotificationOptions. When a Notification is constructed within a service worker it is set automatically, in other environments it needs to be set to a ServiceWorkerRegistration object (allowing it to be overridden inside a service worker is probably okay). (If there's an issue with the ServiceWorkerRegistration object we throw.) If this succeeds, the underlying notification is associated with a service worker. If a notification is associated with a service worker, events are dispatched to the service worker, rather than to Notification objects associated with the notification. These events also expose a new Notification object (cloning is cheap). Suggestions I remember: * Expose promises on Notification objects to see whether a notification has been clicked or closed. (And keep track of such state somewhere.) * Dispatch events to Notification objects as well even if the notification has an associated service worker. Requiring message channel roundtrips for this is cumbersome. This is also tracked on GitHub: https://github.com/whatwg/notifications/issues/19 -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote: After having talked to our web developers, and having talked to Olli, I've come to the following conclusions: * We should consider the case of persistent notifications separate from notifications that automatically close when a page goes away. * Notifications that close when a page goes away does not seem useful on mobile, but could be useful on desktop to enable minimized applications, or applications whose window is covered by other windows, call attention to themselves. Can you provide an example use-case for a persistent notification that goes away when the page does? I can think of transient notifications, and persistent ones that stick around until dismissal, but I can't come up with this in-between case with a few minutes thought. * Persistent vs. non-persistent doesn't seem like a platform difference, but rather two different types of notifications that content could want to create. Yes. Pandora temporarily spawning a notification showing the song title/artist that's playing whenever a new song starts seems useful as a non-persistent notification on any platform. I definitely wouldn't want that sort of thing to stack up on a mobile device. * For persistent notifications, in cases where the application cares about the user clicking on the notification (as opposed to fire-and-forget notifications), we should always send a notification to the service worker. In this scenario it never seems useful to fire an event on the Notification instance since that will just mean multiple codepaths trying to handle the same click. At best that would be wasted performance, at worst it could mean broken UI or application logic. * Same applies to close in addition to click. * For non-persistent notifications, it seems good to not require that a service worker is used. I'm not sure persistent vs non-persistent is quite the line to draw this on. Fire-and-forget vs responsive seems more correct. Most (all?) persistent notifications are responsive, yes, but transient notifications might or might not be. I think it's appropriate and useful for a fire-and-forget notification to be fireable from a normal page, without a service worker. * I'm uncertain about if non-persistent notifications are important enough to target at this point. But I'm heavily biased from having worked mainly on mobile web lately. * Right now the spec requires that whenever a user interacts with a persistent notification, the application that created the notification is immediately started so that we can send the appropriate click/close/future-button-press event to it's service worker. This can be quite expensive. At the very least applications need to be able to indicate that they don't need to be told about the close event. * Even better would likely be content could indicate which events they want fired at the service worker when creating a Notification. Other events would be dropped. This list vary by-notification, not by-app. Yes, seems useful. * Alternatively, maybe we could simply get rid of the close event entirely. Does it have a use-case? I'm also not sure, on first thought, how an app would respond to a close event. I don't think that apps on Android currently care if you close a notification? At least, nothing that I use seems to do anything about it; IRCCloud, for example, doesn't mark mentions as already read if I close the mention notification. Some use-cases would be useful. ~TJ
Re: [whatwg] Notifications and service workers
On Tue, Sep 23, 2014 at 5:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote: After having talked to our web developers, and having talked to Olli, I've come to the following conclusions: * We should consider the case of persistent notifications separate from notifications that automatically close when a page goes away. * Notifications that close when a page goes away does not seem useful on mobile, but could be useful on desktop to enable minimized applications, or applications whose window is covered by other windows, call attention to themselves. Can you provide an example use-case for a persistent notification that goes away when the page does? I'm saying that there are two types of notifications: * Persistent notifications that stick around even after the user closes the app/webpage. * Non-persistent (aka transient) notifications which are not. I'm currently not attaching any particular UX to either. I.e. I'm leaving out *where* these notifications are displayed. I can think of transient notifications, and persistent ones that stick around until dismissal, but I can't come up with this in-between case with a few minutes thought. I agree. * Persistent vs. non-persistent doesn't seem like a platform difference, but rather two different types of notifications that content could want to create. Yes. Pandora temporarily spawning a notification showing the song title/artist that's playing whenever a new song starts seems useful as a non-persistent notification on any platform. I definitely wouldn't want that sort of thing to stack up on a mobile device. Interesting. It's not something I've actually seen myself, but I don't tend to listen to music on my mobile. But it does fit with the general idea that non-persistent notifications solve the use case of allowing background applications to call attention to themselves. * For persistent notifications, in cases where the application cares about the user clicking on the notification (as opposed to fire-and-forget notifications), we should always send a notification to the service worker. In this scenario it never seems useful to fire an event on the Notification instance since that will just mean multiple codepaths trying to handle the same click. At best that would be wasted performance, at worst it could mean broken UI or application logic. * Same applies to close in addition to click. * For non-persistent notifications, it seems good to not require that a service worker is used. I'm not sure persistent vs non-persistent is quite the line to draw this on. Fire-and-forget vs responsive seems more correct. Most (all?) persistent notifications are responsive, yes, but transient notifications might or might not be. I think it's appropriate and useful for a fire-and-forget notification to be fireable from a normal page, without a service worker. I think we are mainly using different vocabulary. I think my non persistent notification is your transient notification. I guess one question is if it's ever useful to have a persistent notification which is fire and forget. I.e. where the application does not want to run code or display UX when the user clicks the notification. My gut instinct is that there's likely some such use cases. / Jonas
