HTML5 pages that expect to remain visible, or to otherwise prevent the system from entering a low-power mode after a long period of no user interaction (eg. YouTube or SoundCloud), are currently not able to distinguish themselves from pages that just use media elements for minor flair.
Chrome has an extension/app API for this in
chrome.power. I think this might be a solid base for a new specification (putting
navigator), with a proposed UX for pages that works like the “this tab is playing sound” icon (with icons for “this tab is keeping the [system/display] awake”). Navigating away from a page would automatically release that page’s keep-awake handle.
There’s a Chromium issue related to this:
One suggestion there was that web pages in fullscreen mode could block the device from sleeping.
There is a spec for that: Wake Lock API
Cool, I’ve edited the thread title accordingly.
6. Additional lock types
The lock request and management mechanism presented in this document can be extended to support additional types of locks by adding new lock request flags to Document interface. E.g. a “system” wake lock could be introduced which would prevent the device’s cpu, radio(s), and other system services from entering a power-saving state while allowing the screen to switch off.
This should actually be specified as part of the draft, since Chrome already has support for it, and pages like music sites have a need for it. (If you need an example for something that’s not ready yet, you could use “lid”, for keeping the screen awake even when the lid is closed, as is being discussed at https://code.google.com/p/chromium/issues/detail?id=287071.)
What about recommendations for the UX for tabs that implement this? Can that be a non-normative section of the spec?
Also, how should a polyfill extend an evented property-getting-and-setting API like this? Should it call
can you raise these as issues on the github repo? https://github.com/w3c/wake-lock/issues
Answering my own question here: since these use fixed properties, they can be handled with ordinary getters and setters.
I don’t know if this has been considered yet (and I’ll probably have to post this as a GitHub issue if that’s what the Wake Lock spec team is following more than WICG), but inhibiting the screensaver can be a security concern. If I’m a penetration tester, and I can coerce an employee to place their computer in a state where the screensaver or power management (which they are accommodated to relying on for locking their workstation) doesn’t trigger, I’ve opened a window I can sneak into that would have otherwise been shut (schedule an interview 30 minutes into their lunch hour, when they expect I wouldn’t be able to do anything in their office until they get back).