W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] Proposal: Wake Lock API

From: (wrong string) ński <kornel@geekhood.net>
Date: Mon, 18 Aug 2014 23:24:36 +0100
Message-Id: <C3BE728B-8FCD-4CA2-BA27-E9F731E0349D@geekhood.net>
To: WHAT Working Group <whatwg@lists.whatwg.org>
Cc: Mounir Lamouri <mounir@lamouri.fr>, Jonas Sicking <jonas@sicking.cc>, Marcos Caceres <w3c@marcosc.com>
I think it'd be unfortunate if this API had just one shared lock per browsing context and required components on the page to coordinate locking, but provided no means to do so. This will force authors of libraries and components to create dummy iframes just to have their private lock, and libraries/pages without such workaround will be messing up each other's locks.

Having just a single shared DOM0-style event handler navigator.wakeLock.onlost looks especially jarring. I would expect this to be a proper DOM event that can be used with normal addEventListener (please avoid repeating the mistake of matchMedia).


To make some coordination possible, the simplest method could be to keep track of number of lock requests and releases, like retain/release in Objective-C:

navigator.wakeLock.request("screen"); // locks
navigator.wakeLock.request("screen"); // increases lock count
navigator.wakeLock.release("screen"); // not released yet, but decreases lock count
navigator.wakeLock.release("screen"); // now released for real

However, as you probably know from Objective-C, perfect balancing of retain/release takes care and discipline. Personally, I wouldn't trust all 3rd party libraries/widgets/ads to be careful with this. In fact, I expect some "clever" libraries to ruin this with:

while(navigator.wakeLock.isHeld("screen")) navigator.wakeLock.release("screen"); // just release the damn thing in my leaky code!


Therefore, if WakeLock needs to be purely JS API, I strongly prefer having WakeLock available only as an object instance, but without exposing GC behaviorif it's lost, it's like a missing release call. 

If devtools ever get monitoring of unhanded errors in Promise objects, they could also warn against lost WakeLock objectsit's the same type of problem dependent on GC.

I'm assuming that release would work only once on each lock object:

var lock = new WakeLock("screen");
lock.release();
lock.release(); // ignored, so it doesn't unlock any other component's lock

This makes coordination easier: each page component can easily create their own lock independently (without needing to create an iframe to get their own lock), and can't release any other component's lock.


-- 
regards, Kornel
Received on Monday, 18 August 2014 22:25:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC