On Mon, Aug 18, 2014 at 4:21 PM, Kornel Lesiński <[email protected]> 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
