W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] Proposal: Wake Lock API

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 19 Aug 2014 11:07:34 -0700
Message-ID: <CA+c2ei8W3PmySUuRjF530CQK+GZCwxqXOO=eSxqRhsJDRTnjEw@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Marcos Caceres <w3c@marcosc.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC