Re: Service worker popup (rich notification)
On 02.10.2014 21:34, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 2, 2014 at 8:27 PM, John Mellor joh...@google.com wrote: This seems to either require a somewhat stronger trust signal from the user, or a very easy mechanism for revoking the permission if the website does spam you; and probably in either case showing the url bar should be compulsory to prevent phishing. But this isn't something we've thought about deeply yet. Indeed. The Notifications API is nice, but it's not suitable for this. You need a browsing context of sorts so you can show images, video, buttons, etc. Indeed. I wouldn't call these notifications at all. What's needed here is to launch full browser windows so that we can display full-screen or full-window UIs to the user. To make matters even more complicated, generally speaking you want to be able to do this on a mobile device, even if it's locked. I.e. an alarm clock app wouldn't be terribly useful if it only worked when the device was unlocked. And a skype app wouldn't be terribly useful if you could only receive calls when the device was unlocked. Fortunately, while this goes outside the browser window, it doesn't break the same-origin boundary. So it should be quite possible to solve this the same way we're planning on solving other such APIs, like storage, indexedDB and notifications. I.e. make the API async and then leave it up to UAs to implement policies. / Jonas We have something similar in FirefoxOS per-app window: window.open(url, , dialog); We also have the so called attention screen, that requires a special permission and is on top of everything (e.g. for alarm clocks and incoming calls): window.open(url, , attention); Which of these use-cases are we discussing here?
Re: Service worker popup (rich notification)
On Mon, Oct 6, 2014 at 11:45 AM, Frederik Braun fbr...@mozilla.com wrote: We have something similar in FirefoxOS per-app window: window.open(url, , dialog); We also have the so called attention screen, that requires a special permission and is on top of everything (e.g. for alarm clocks and incoming calls): window.open(url, , attention); Which of these use-cases are we discussing here? Either of these could be interesting. In particular the case I'm interested in is showing UI to the user when the application is not running and a push message arrives at the service worker. -- https://annevankesteren.nl/
Re: Service worker popup (rich notification)
On Thu, Oct 2, 2014 at 2:48 PM, John Mellor joh...@google.com wrote: API-wise, you probably know that the ServiceWorkerClient interface lets a SW focus existing same-origin tabs or open new ones (by constructing a client; perhaps confusingly). Constructing an object as a means of opening a new window seems really weird. Is that the pattern common JavaScript widget libraries adopt? -- https://annevankesteren.nl/
RE: Service worker popup (rich notification)
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
Constructing an object as a means of opening a new window seems really weird.
Is that the pattern common JavaScript widget libraries adopt?
Says the creator of `new Notification({...})` ;)
But, I think the answer to your question is indeed yes. It's good to have an
object representing the new window, that you can manipulate (e.g. call a
`.close()` method on, or send messages to).
That said, I can't think of any examples off the top of my head, so I might be
wrong :(
Service worker popup (rich notification)
I wonder how much thought has been given to creating a popup (rich notification if you will) from a service worker. Combined with the push API this is what will enable e.g. Skype to cease being a native application. There's also some potential other uses for this. -- https://annevankesteren.nl/
Re: Service worker popup (rich notification)
On the one hand, there are some great use cases for this (video calls, alarm clocks, two-factor authentication, sending a map from desktop to mobile before you leave the house, etc). On the other hand, browsers have traditionally had to block popups except following a user gesture, and it's easy to imagine that an API for showing popups from the background after some time delay (e.g. push or background sync) would be abused (for spam or even phishing). So I guess this is something we'll want to support eventually, but it's blocked on coming up with clear UI for safely granting and revoking permission to show popups from the background. API-wise, you probably know that the ServiceWorkerClient interface https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-client lets a SW focus existing same-origin tabs or open new ones (by constructing a client; perhaps confusingly). But at least in the short term, we've been planning to only allow that from a notificationclick event (i.e. following a user gesture). --John On 2 October 2014 09:04, Anne van Kesteren ann...@annevk.nl wrote: I wonder how much thought has been given to creating a popup (rich notification if you will) from a service worker. Combined with the push API this is what will enable e.g. Skype to cease being a native application. There's also some potential other uses for this. -- https://annevankesteren.nl/
Re: Service worker popup (rich notification)
On 2 October 2014 05:48, John Mellor joh...@google.com wrote: So I guess this is something we'll want to support eventually, but it's blocked on coming up with clear UI for safely granting and revoking permission to show popups from the background. Doesn't this already exist, at least in some form? Gecko already has permissions management functions for Show Notifications.
Re: Service worker popup (rich notification)
Notifications tend to be relatively unobtrusive and sit in a UA/OS-specific notification tray, usually in a corner of the screen; what we're talking about here (at least on mobile) would be launching a maximised (or possibly fullscreen) browser window on top of whatever the user is currently doing. This seems to either require a somewhat stronger trust signal from the user, or a very easy mechanism for revoking the permission if the website does spam you; and probably in either case showing the url bar should be compulsory to prevent phishing. But this isn't something we've thought about deeply yet. On 2 October 2014 17:47, Martin Thomson martin.thom...@gmail.com wrote: On 2 October 2014 05:48, John Mellor joh...@google.com wrote: So I guess this is something we'll want to support eventually, but it's blocked on coming up with clear UI for safely granting and revoking permission to show popups from the background. Doesn't this already exist, at least in some form? Gecko already has permissions management functions for Show Notifications.
Re: Service worker popup (rich notification)
On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 2, 2014 at 8:27 PM, John Mellor joh...@google.com wrote: This seems to either require a somewhat stronger trust signal from the user, or a very easy mechanism for revoking the permission if the website does spam you; and probably in either case showing the url bar should be compulsory to prevent phishing. But this isn't something we've thought about deeply yet. Indeed. The Notifications API is nice, but it's not suitable for this. You need a browsing context of sorts so you can show images, video, buttons, etc. Indeed. I wouldn't call these notifications at all. What's needed here is to launch full browser windows so that we can display full-screen or full-window UIs to the user. To make matters even more complicated, generally speaking you want to be able to do this on a mobile device, even if it's locked. I.e. an alarm clock app wouldn't be terribly useful if it only worked when the device was unlocked. And a skype app wouldn't be terribly useful if you could only receive calls when the device was unlocked. Fortunately, while this goes outside the browser window, it doesn't break the same-origin boundary. So it should be quite possible to solve this the same way we're planning on solving other such APIs, like storage, indexedDB and notifications. I.e. make the API async and then leave it up to UAs to implement policies. / Jonas
