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: Mounir Lamouri <mounir@lamouri.fr>
Date: Mon, 01 Sep 2014 20:56:16 +1000
Message-Id: <1409568976.482305.158988961.6E0EC5A7@webmail.messagingengine.com>
To: Marcos Caceres <w3c@marcosc.com>, Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-script-coord@w3.org
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.

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.

-- Mounir
Received on Monday, 1 September 2014 10:56:39 UTC

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