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

In general I feel this thread has taken a turn for the complex. Why don't we just do what other platforms do, and provide a simple global request/release mechanism (or toggleable Boolean property!), which developers can build on top of? A lot of the ideas here seem to be trying to create the perfect, developer-friendly, foolproof API. Some of them seem quite clever too, tying to page visibility and the like. But all of them could be built, as libraries, on top of a global request/release. That way users could get reference counting if they want that, visibility-based locking if they want that, promise-based locking if they want that, timeouts if they want those, or even just not do any of those if their use case is simple enough that it doesn't warrant anything more complicated than what they are already doing on existing platforms.

We don't need to solve Hard Problems in Programming (TM) before we expose a wake lock API. Leave that as a subsequent step, which users can do, while we move on to exposing more missing platform capabilities

> On Aug 18, 2014, at 19:52, "Marcos Caceres" <w3c@marcosc.com> wrote:
> 
> 
> 
>> 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 we 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 Tuesday, 19 August 2014 00:11:17 UTC