- From: Kornel Lesiński <kornel@geekhood.net>
- Date: Tue, 19 Aug 2014 00:21:08 +0100
- To: WHAT Working Group <whatwg@lists.whatwg.org>
- Cc: Marcos Caceres <w3c@marcosc.com>
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). 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? ;) -- regards, Kornel
Received on Monday, 18 August 2014 23:21:35 UTC