Re: [whatwg] Proposal: Wake Lock API

On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
>> Note that in the API that I'm proposing, there is no way to
>> accidentally rely on GC behavior. If a WakeLock object is GCed before
>> it has been release()ed, then the lock is held indefinitely (until the
>> user leaves the page of course).
>>
>> I.e. an unbalanced request() and release() in both the currently
>> proposed API, and in the API that I propose behave the same, the lock
>> is held indefinitely. Any objects getting GCed does not change this.
>
> I overlooked that aspect, my apologies. It sounds good. I am not sure if
> that would be safer than global methods in the sense that developers
> will still be able to shoot themselves in the foot by not calling
> .release() or might assume that .release() will be called upon object
> destruction.

Indeed. I can't think of a way to fix that without also breaking some
use cases. I.e. we could forcefully release all locks after a timeout,
but that'll definitely break some use cases such as long videos, or
heavy background processing.

> How would you handle feature detection with this design?

This is a good question. I don't have a better solution than adding
separate DisplayWakeLock() and SystemWakeLock() classes.

/ Jonas

Received on Tuesday, 19 August 2014 18:08:29 UTC