Re: [whatwg] Proposal: Wake Lock API

On Monday, August 18, 2014 at 6:24 PM, Kornel Lesiński wrote:

> 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.  


The API allows scripts to check which locks are currently held (as either a `isHeld()` or `getCurrentLocks()`, for which I just sent a PR for).   
> 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.

Currently, iframes are not allowed to have locks - only top-level browsing contexts are. This is to avoid things like embedded ads from requesting wake 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).

Oops! I forgot to put that `WakeLock` inherits from `EventTarget`. It's always been the intention that you will have .addEventListener! I've sent a PR to fix this.  
> 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


In my dummy implementation, I've just been using (the Swift equivalent of):
[UIApplication sharedApplication].idleTimerDisabled = YES;


On MacOS, I thought the "right thing to do" (tm) according to Apple was [1] (see listing 2)? I'm pretty sure that's what we do already in Gecko for videos as we've been investigating repurposing the video code for wake locks.  

So, I've not seen the request/release behavior you describe above (at least not in the context of wake locks on MacOS/iOS). I guess it's used as an idiom maybe in other places?
> However, as you probably know from Objective-C,

Full disclosure, I barely know 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!
That would just halt the browser as the script would never complete: currently releasing happens async once the system acknowledges that the release has been granted. I'm not sure if there is a use case for that behavior - it's just what is currently/sorta roughly proposed in the spec.  
> Therefore, if WakeLock needs to be purely JS API, I strongly prefer having WakeLock available only as an object instance, but without exposing GC behavior—if 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 objects—it'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.
Personally, I don't know if I agree that it makes coordination easier. Seems that having a centralized place to check what is currently being held makes life a lot easier, because it allows scripts to check if they actually need to request a lock or not. If you have some objects requesting and others releasing, then it makes a huge mess because you need to track down which object screwed up the lock. And if GC also then works to release the locks, then there is no certainty as to what is actually releasing the lock or when.   


[1] https://developer.apple.com/library/mac/qa/qa1340/_index.html

Received on Monday, 18 August 2014 23:37:59 UTC