W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Wake Lock API as [Observable] candidate, Re: [whatwg] Object.observe()able properties on the web platform

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
Message-ID: <E8915D70019747998DA0DD69358DD46F@marcosc.com>


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC