- From: Frederik Braun <fbraun@mozilla.com>
- Date: Mon, 06 Oct 2014 11:45:49 +0200
- To: public-webapps@w3.org
On 02.10.2014 21:34, Jonas Sicking wrote: > On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> On Thu, Oct 2, 2014 at 8:27 PM, John Mellor <johnme@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?
Received on Monday, 6 October 2014 09:46:18 UTC