On 02.10.2014 21:34, Jonas Sicking wrote: > On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren <[email protected]> wrote: >> On Thu, Oct 2, 2014 at 8:27 PM, John Mellor <[email protected]> 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?
