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

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.  


Received on Monday, 1 September 2014 17:03:38 UTC