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

On Monday, August 18, 2014 at 7:21 PM, Kornel Lesiński 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.

Sure. At least on a mobile device, it's easy enough for the user to turn off the screen (or just switch apps or browser tabs)... on laptops, it could be a problem. However, MacOS (at least) is pretty good at telling users if an app is eating too much battery. So this could be also handled at the system level.  
> 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.

I think that would be nice, actually. It's at least a kinda workaround to having to check if something is in the drawable area manually.  

However, it still doesn't really deal with the case where the dev forgets to release the lock. What is nicer is combining this with a timeout:

navigator.wakeLock.request("screen", {element: myCanvas, timeout: aFewMinutes});

That would be the most ideal solution for me personally. Just set it, and forget it.  
  
> 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).

Yes, absolutely. So long as CSS lacks some way to detect if something is offscreen, it makes sense. The current ways of checking if an element is within the viewport are quite expensive (bunch of jQuery plugins do this - and I think they depend on the onscroll event).  
> With CPU lock it's less clear cut. I think tying it to a notification may be a good idea.

Need to think about it.  
> Alternatively, perhaps the lock itself could be an instance of the <progress> element that author is supposed to insert to the document? ;)

heh:) Yeah, need to think about that.

Received on Monday, 18 August 2014 23:52:58 UTC