- From: Marcos Caceres <w3c@marcosc.com>
- Date: Tue, 15 Jul 2014 15:21:48 -0400
- To: whatwg@lists.whatwg.org
## 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(){
navigator.wakeLock.release("display")
} );
## 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