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

Re: [whatwg] Preventing wake lock leaks with DOM nodes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 18 Aug 2014 16:29:12 -0700
Message-ID: <CAAWBYDDcRTMnYH4WMXr1EwqLLE5DAS0Uh97AAncA-ViP5=BwVw@mail.gmail.com>
To: Kornel Lesiński <kornel@geekhood.net>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Marcos Caceres <w3c@marcosc.com>
On Mon, Aug 18, 2014 at 4:21 PM, Kornel Lesiński <kornel@geekhood.net> wrote:
> My biggest concern with the WakeLock API is that it's easy to forget (or fail) to release the lock.
> It's not a problem with the API per se, but a programming problem in general: resource management in non-trivial programs is hard. WakeLocks are especially problematic in this regard, as a "leaked" lock won't cause any immediate problems for the developer, so this type of bug can easily go unnoticed.
> So I think lifetime of WakeLocks needs to be attached to something visible to make failure to release the lock immediately obvious.
> In case of screen lock it's especially easy: the whole purpose of this lock is to keep something visible on screen, so we can require that something to be explicitly connected to the lock.
> For example if I were creating a widget that displays a presentation on the page, I could attach the screen lock to the <canvas> or <svg> element that holds the presentation:
> new navigator.ScreenLock(myCanvas);
> and if the canvas was removed from the document or hidden in any way, then the browser could turn the screen off as usual, and I wouldn't have to do anything!
> It's nearly impossible to forget to remove a visible DOM element from the document — the mistake is likely to be quite obviously visible. If screen lock lifetime was dependent on visibility of a DOM element, then it would also be very hard to leak the lock without noticing it!
> (that's a variant of "wake-lock:display" CSS proposal, but less explicitly dependent on CSS).

Good, but you lose the ability to key the wake-lock to
Selectors-exposed UA state (like "video:playing"), or directly to your
app's own state (via some class that gets set/removed by your app at
some point in its lifecycle).

But if the CSS part is distasteful, I agree that this works reasonably
well - there is *absolutely no reason* to screenlock based on an
element that's not visible on screen.

> With CPU lock it's less clear cut. I think tying it to a notification may be a good idea. Alternatively, perhaps the lock itself could be an instance of the <progress> element that author is supposed to insert to the document? ;)

Just pass a promise to the CpuLock constructor, and have it
auto-release when the promise is settled?  You'll generally be
CPU-locking to wait for some operation to finish, and a lot of those
types of operations vend promises these days (or will in the future).

Received on Monday, 18 August 2014 23:30:01 UTC

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