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

[whatwg] Proposal: Wake Lock API

From: Marcos Caceres <w3c@marcosc.com>
Date: Tue, 15 Jul 2014 15:21:48 -0400
To: whatwg@lists.whatwg.org
Message-ID: <etPan.53c57f4d.216231b.8884@Marcoss-MacBook-Pro.local>
## Use cases 
A website wants the prevent a device from entering a power-saving state to allow a user to complete a task where it's not practical for the user to touch the screen (e.g., a maps application while driving, a VR headset like Cardboard).  

A website needs to be able to complete a task, but without requiring the user to keep the screen on (e.g., importing and processing a bunch of contacts). Having a wake lock on the "system" would allow the user to turn off the screen, while allowing a webpage (or worker) to continue processing some data in the background.     

A complete list of use and abuse cases can be found at [1].  
## Workarounds 
There is some evidence that "…Developers are resorting to hacks like playing hidden videos to prevent the screen from sleeping." [2] 

## Why now? 
There are lots of applications on the Web that would benefit from this feature. E.g., maps, games, cooking websites, ebooks, and sites that stream non-video content in real time (e.g., sports scores). Also, both Google and Mozilla are looking into VR, and they will likely need this (see [2]). See [1] for list of applications that rely on this feature in other platforms. 

Other platforms that already support this kind of feature: iOS, Android, Firefox OS, Windows mobile, and Tizen.  

# Proposal: 

partial interface Navigator { 
   attribute WakeLock wakeLock; 

interface WakeLock{ 
   promise request(WakeLockType type); 
   void release(WakeLockType type); 

enum WakeLockType{ "system", "display" } 

## Example 
//lock display when the recipe is showing: 
$( "#recipe" ).on( "show", function(){ 
   navigator.wakeLock.request("display").then(haveFun, boo) 
} ); 

//release lock: 
$( "#recipe" ).on( "hide", function(){ 
} ); 

## Optional enhancements 

### Timeouts  
We are thinking of adding a dictionary to hint at the system the amount of time it should hold the lock for (in ms). So, then the developer can express holding the lock for 5 minutes (e.g., ebook case, instead of having to bind a whole bunch of listeners and constantly having to request the wake lock). This would allow the UA to add whatever time the developer requested to its normal wake lock timer + additional time the developer might want. If the timeout is less than the default timeout, it can just be ignored. 

dictionary WakeLockOptions{ 
  unsigned long timeout; 

For example: 
//I only need this for ~5 mins here. 
var options = {timeout: 1000 * 60 * 5}; 
navigator.wakeLock.request("display", options);  

### Events  
It might be necessary for applications to be notified, via an event, if they've lost a lock after one was granted to it.  

### Check if lock is already set 
It might be useful to also have a way of checking if a lock is already set: 

readonly attribute WakeLockType? lockType  

Appreciate any feedback on the design and help with the security model.   

[1] https://w3c-webmob.github.io/wake-lock-use-cases/
[2] https://code.google.com/p/chromium/issues/detail?id=386255
Received on Tuesday, 15 July 2014 19:22:30 UTC

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