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

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).

~TJ

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