A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Wake Lock API (suppressing power management/screensavers)

stuartpb
2015-02-25

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 requestKeepAwake and releaseKeepAwake on window or 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.

tagawa
2015-02-27

There’s a Chromium issue related to this: https://code.google.com/p/chromium/issues/detail?id=111043

One suggestion there was that web pages in fullscreen mode could block the device from sleeping.

dontcallmedom
2015-03-02

There is a spec for that: Wake Lock API

stuartpb
2015-03-23

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 Object.observe on document?

dontcallmedom
2015-03-23

can you raise these as issues on the github repo? https://github.com/w3c/wake-lock/issues

stuartpb
2015-04-02

Answering my own question here: since these use fixed properties, they can be handled with ordinary getters and setters.

stuartpb
2015-08-07

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