Intent to Ship: Screen Wake Lock API

[Reilly Grant]

Contact emails

rei...@chromium.org, wande...@chromium.org, natt...@chromium.org

Spec

https://w3c.github.io/wake-lock/

TAG reviews

https://github.com/w3ctag/design-reviews/issues/32

https://github.com/w3ctag/design-reviews/issues/126

Summary

This API allows a site to prevent the system from automatically locking or powering off the display. Sites currently accomplish this through libraries such as NoSleep.js, which abuse a <video> tag to create a wake lock. In this API, to make this request the page must already be visible and the user can override the lock by switching to another tab or manually locking or powering off their display.

The current draft specification defines two types of wake locks, “screen” and “system”. This intent refers to the former, while the latter would allow a site to prevent the system from going to sleep even if the screen is off. The use cases for this type, as well as the security and privacy considerations are still being analyzed and so this intent is limited only to the “screen” type.

On request from Mozilla the working group will be splitting the “system” wake lock type into a separate document for further development.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/KMNZmMF1_H4/U6EGekDrBwAJ

Link to Origin Trial feedback summary

We saw generally good adoption in the origin trial and great feedback on how likely developers were to keep using the API. While the direct data is confidential, those who have sufficient business reason to see the results can request access to this doc with a summary. Non-confidentially, I can share that 89% of signups said they were “extremely likely” to keep using the API, with the remaining 11% saying they were “moderately likely”. Through sampling of the signups we saw no sites using the API in any way we would consider malicious or not the in the users best interest, not that we would expect malicious sites to sign up for an origin trial. Some example sites included a few cooking recipe sites, slideshow presentation applications, and a live streaming service. 

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://reillyeon.github.io/scraps/wakelock.html

Debuggability

This is a Javascript API and code using it can be inspected as usual through the DevTools console. In the future it may be useful for developers to surface wake lock state through DevTools.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: No signals, there is an on-going standards positions discussion where they have suggested reducing the scope of the specification, which we are doing.

Safari: No signals, a WebKit bug was filed on 2019-12-10 without any comment from Apple.

Web / Framework developers: Positive (from Origin Trial feedback)

Ergonomics

This API is designed to be simple and standalone.

Activation

This API replaces the NoSleep.js library, which abuses a <video> tag to keep the user’s screen awake. There is an issue open to let the developers of this library know about this API. For compatibility with browsers not implementing this API support could be added to this library with a fallback to the existing <video> tag hack.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/results/wake-lock

Some of these tests are failing because they haven’t been updated to use test_runner.set_permission(). I have patches out for review to fix that.

Entry on the feature dashboard

https://chromestatus.com/feature/4636879949398016

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[masatak...@gmail.com]

Thomas Steiner has been pinging webkit folks on their position over webkit-dev.

https://lists.webkit.org/pipermail/webkit-dev/2019-December/thread.html#30995

https://lists.webkit.org/pipermail/webkit-dev/2020-February/thread.html#31066

perhaps incorporate what they say in the position?

[Mike West]

LGTM1. The main concern here is the `system` lock, and that's punted out of this intent. The `screen` type removes the incentive to use the `<video>` hack as a workaround. This gives the browser more control over the mechanism, which itself seems clearly valuable.

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e9b94db-7475-4ba6-b7db-ac8870169c34%40chromium.org.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DegyRv%3DkMiLqWsAuZdu5q74Gu995iCUFrOwKgeRW6j3CQ%40mail.gmail.com.

[Daniel Bratell]

LGTM3  for the screen/display wake lock (just to make it 100% clear that the system wake lock is pushed forward even if not all documents have yet been updated).

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8eVgwjJxYBFS_z26xPKoEs6u9fQw_gLUOEZ7HQqX8ptg%40mail.gmail.com.