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
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)?
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)
This API is designed to be simple and standalone.
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.
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
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.
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.
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).
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.