- From: Marcos Caceres <w3c@marcosc.com>
- Date: Mon, 1 Sep 2014 13:03:06 -0400
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-script-coord@w3.org
On Monday, September 1, 2014 at 6:56 AM, Mounir Lamouri wrote: > On Tue, 26 Aug 2014, at 04:55, Marcos Caceres wrote: > > 2. The API should probably be restricted to the top-level browsing > > context (don't want random advertisements in an iframe keeping the screen > > on, for example). As far as observing is concerned, I would guess this > > one doesn't matter - just trying to point out that setting behaviour is > > contextual. > > I disagree. We should allow iframes to use the wakelock api. Embedders > can prevent this to happen via the sandbox attribute. Ok, let's use that. > On Tue, 26 Aug 2014, at 08:44, Jonas Sicking wrote: > > Why? Just assume that if your lock instance hasn't been granted, that > > the screen isn't locked. > > > > It seems that the main difference between your proposal and Marcos' is > that you don't want caller A requesting a wake lock having a side effect > on caller B requesting a wake lock. In other words, A and B can't be > aware of each other. That means that you do not expect to have a global > place to check if the screen has a wake lock applying to it, right? It > sounds reasonable and not having side effects would probably simplify > the API. > Agree. Currently working on specifying what Jonas and others proposed. PR coming in the next few days. See: https://github.com/w3c/wake-lock/issues/39#issuecomment-53460881
Received on Monday, 1 September 2014 17:03:38 UTC