Intent to Implement: Wake Lock API based on Promise

275 views
Skip to first unread message

mrunal...@intel.com

unread,
Apr 11, 2018, 3:02:55 PM4/11/18
to blink-dev, Anssi Kostiainen

Contact emails

mrunal...@intel.com, anssi.ko...@intel.com


Spec

https://www.w3.org/TR/wake-lock/


Summary

This 2nd iteration of Wake lock API makes use of Promises and introduces Wake Lock Types.


Motivation

Currently there is no standard way to prevent any aspect of device such as screen or cpu cycles going into power saving state. Some web developers use hacks such as adding very tiny video element to the page and keep looping until some timeout. There are frameworks such as NoSleep.js which make it easy to add such hacks. Wake Lock API brings in standard, secure and safe way to prevent some aspect of device such as Screen or CPU cycles going into power saving state. In this latest iteration of API we aim to address some of the shortcomings of older api which was limited to screen Wake Lock and didn’t address some of the security and privacy issues.


Risks

Interoperability and Compatibility

The risk is low even though other browsers haven’t implemented it as there is a mature spec with Web Platform Tests. Also this api should have small footprint. Compatibility risk should also be low as older api is still experimental and doesn’t any overlap. Older api could be removed once this api is implemented.


Edge: No signals

Firefox: No signals(Firefox OS implemented non-standard API)

Safari: No signals

Web developers: Positive


Ergonomics

This api could be used along with other Sensor API’s such as accelerometer or gyroscope.


Activation

Since this would be a promise based implementation it should be relatively easy to use this api. Polyfills would be helpful.


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

Yes.


Is this feature fully tested by web-platform-tests?

Even though this is not an Intent to Ship, you can find the web platform tests for Wake Lock API here,

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

Above tests will be used to test this Wake Lock API implementation.


Link to entry on the feature dashboard

TBD.


Requesting approval to ship?

No.


Joe Medley

unread,
Apr 12, 2018, 10:30:39 AM4/12/18
to mrunal...@intel.com, blink-dev, anssi.ko...@intel.com
Do you have a bug I can star to follow the progress of this?
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


--
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/387c9579-a8f9-4d8b-8819-a120c957345e%40chromium.org.

Kapade, Mrunal

unread,
Apr 12, 2018, 2:35:34 PM4/12/18
to Joe Medley, blink-dev, Kostiainen, Anssi
Oops...I thought I added OWP Launch Tracking bug but since the Intent to Implement template didn't have it I forgot to add it later.
Anyways you can track the bug here, https://bugs.chromium.org/p/chromium/issues/detail?id=257511

Also if someone can give me access to add feature to chromestatus.com that will be great.

From: Joe Medley [jme...@google.com]
Sent: Thursday, April 12, 2018 7:30 AM
To: Kapade, Mrunal
Cc: blink-dev; Kostiainen, Anssi
Subject: Re: [blink-dev] Intent to Implement: Wake Lock API based on Promise

Joe Medley

unread,
Apr 12, 2018, 3:58:25 PM4/12/18
to mrunal...@intel.com, blink-dev, anssi.ko...@intel.com

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Kapade, Mrunal

unread,
Apr 19, 2018, 5:03:56 PM4/19/18
to Joe Medley, blink-dev, Kostiainen, Anssi
Yep, I did submit my request before sending this intent but haven’t got any response from anyone yet. If you can pass this to someone who manages chromestatus.com that will be great.

Thanks,
-Mrunal 

Eric Bidelman

unread,
Apr 23, 2018, 11:56:11 AM4/23/18
to mrunal...@intel.com, Joe Medley, blink-dev, anssi.ko...@intel.com
You should have access now.

Kapade, Mrunal

unread,
Apr 24, 2018, 7:24:12 PM4/24/18
to Eric Bidelman, Joe Medley, blink-dev, Kostiainen, Anssi
Thank you. I have created an entry on feature dashboard now,
https://www.chromestatus.com/feature/4636879949398016

Mrunal

From: Eric Bidelman [ericbi...@chromium.org]
Sent: Monday, April 23, 2018 8:55 AM
To: Kapade, Mrunal
Cc: Joe Medley; blink-dev; Kostiainen, Anssi

jyas...@google.com

unread,
Dec 18, 2018, 1:01:43 PM12/18/18
to blink-dev, anssi.ko...@intel.com
Sorry for missing this when you first sent it.

I'm concerned about the "system" wakelock type. It's specified to "prevents device's CPU from entering a standby mode so that the programs can continue running." However, this omits several relevant aspects of the web stack. I've filed some bugs against the spec, but I want to make sure the other informed folks on blink-dev know to point out anything I'm missing below.

* CPUs have all sorts of standby modes with different power needs and responsiveness levels. Does this wakelock require the CPU to be running at its top power mode continuously, even if the website is just waiting for, say, the user to change their location?
* How many CPUs does the wakelock apply to in a device with multiple CPUs?
* There's a web browser sitting between the website and the CPU: even if the CPU is running full tilt, the browser may not deliver events to the website or give it any CPU time to execute. I know of https://wicg.github.io/page-lifecycle/ that's trying to explain these browser-level restrictions, but there may be other documents involved. Wake Locks ought to override this, but you need to specify how. It's possible that a single "system" wake lock type isn't sufficient.


Separately, I want to make sure that you're in contact with the security UI team, to make sure that the "system" wakelock gets the right permission UX, to prevent pages from surreptitiously mining bitcoin or tracking a user's location. What permission UX are you planning?

Thanks,
Jeffrey

Torne (Richard Coles)

unread,
Dec 18, 2018, 1:47:32 PM12/18/18
to jyas...@google.com, blink-dev, anssi.ko...@intel.com
On Tue, 18 Dec 2018 at 13:01 jyasskin via blink-dev <blin...@chromium.org> wrote:
Sorry for missing this when you first sent it.

I'm concerned about the "system" wakelock type. It's specified to "prevents device's CPU from entering a standby mode so that the programs can continue running." However, this omits several relevant aspects of the web stack. I've filed some bugs against the spec, but I want to make sure the other informed folks on blink-dev know to point out anything I'm missing below.

* CPUs have all sorts of standby modes with different power needs and responsiveness levels. Does this wakelock require the CPU to be running at its top power mode continuously, even if the website is just waiting for, say, the user to change their location?
* How many CPUs does the wakelock apply to in a device with multiple CPUs?

I think this will have to be very minimal guarantees due to the underlying platform behaviour on some systems: for example Android's CPU wakelock only means that the system will not be *completely* asleep: it doesn't guarantee anything about performance/availability of cores at all, it only means that if one of your threads is in "runnable" state, it will be eligible to be scheduled under the normal scheduler rules. The sleep state on Android stops the entire CPU and only wakes it for specially designated events (whitelisted timers created by the system, certain peripheral interrupts, etc), so the scheduler is no longer running at all.
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

mrunal...@intel.com

unread,
Dec 21, 2018, 7:07:50 PM12/21/18
to blink-dev, anssi.ko...@intel.com
On Tuesday, December 18, 2018 at 10:01:43 AM UTC-8, Jeffrey Yasskin wrote:
Sorry for missing this when you first sent it.

I'm concerned about the "system" wakelock type. It's specified to "prevents device's CPU from entering a standby mode so that the programs can continue running." However, this omits several relevant aspects of the web stack. I've filed some bugs against the spec, but I want to make sure the other informed folks on blink-dev know to point out anything I'm missing below.

* CPUs have all sorts of standby modes with different power needs and responsiveness levels. Does this wakelock require the CPU to be running at its top power mode continuously, even if the website is just waiting for, say, the user to change their location?
The Blink side of Wake Lock implementation relies on the mojo Wake Lock device service. At least Blink side implementation we are not manipulating the power mode directly and I don't think this will change in near future. 

* How many CPUs does the wakelock apply to in a device with multiple CPUs?
As I mentioned above since we use mojo Wake Lock device service we don't control how many CPUs or cores it apples the lock on.

* There's a web browser sitting between the website and the CPU: even if the CPU is running full tilt, the browser may not deliver events to the website or give it any CPU time to execute. I know of https://wicg.github.io/page-lifecycle/ that's trying to explain these browser-level restrictions, but there may be other documents involved. Wake Locks ought to override this, but you need to specify how. It's possible that a single "system" wake lock type isn't sufficient.
I am not sure if I understand your question completely here. Are you asking what will happen if there are multiple tabs requesting system wakelock and/or tabs requesting system wake lock are backgrounded? If you can clarify with examples that will be great.



Separately, I want to make sure that you're in contact with the security UI team, to make sure that the "system" wakelock gets the right permission UX, to prevent pages from surreptitiously mining bitcoin or tracking a user's location. What permission UX are you planning?
 This is a good point. The issue of permissions and how to handle them is actively being discussed here, https://github.com/w3c/wake-lock/issues/140. Wouldn't permissions for user's location fall under Geolocation settings though? Not sure how this is related to Wake Lock.


Thanks,
Jeffrey

Reilly Grant

unread,
Dec 26, 2018, 2:08:16 PM12/26/18
to mrunal...@intel.com, blink-dev, Kostiainen, Anssi
On Fri, Dec 21, 2018 at 4:07 PM <mrunal...@intel.com> wrote:
On Tuesday, December 18, 2018 at 10:01:43 AM UTC-8, Jeffrey Yasskin wrote:
Sorry for missing this when you first sent it.

I'm concerned about the "system" wakelock type. It's specified to "prevents device's CPU from entering a standby mode so that the programs can continue running." However, this omits several relevant aspects of the web stack. I've filed some bugs against the spec, but I want to make sure the other informed folks on blink-dev know to point out anything I'm missing below.

* CPUs have all sorts of standby modes with different power needs and responsiveness levels. Does this wakelock require the CPU to be running at its top power mode continuously, even if the website is just waiting for, say, the user to change their location?
The Blink side of Wake Lock implementation relies on the mojo Wake Lock device service. At least Blink side implementation we are not manipulating the power mode directly and I don't think this will change in near future. 

* How many CPUs does the wakelock apply to in a device with multiple CPUs?
As I mentioned above since we use mojo Wake Lock device service we don't control how many CPUs or cores it apples the lock on.

We shouldn't think of a a Mojo service as something unknowable and unchanging. It is part of the Chromium source just as much as Blink is. We should understand what its capability are and if it needs to change to support an API implemented in Blink then it must change.
 
* There's a web browser sitting between the website and the CPU: even if the CPU is running full tilt, the browser may not deliver events to the website or give it any CPU time to execute. I know of https://wicg.github.io/page-lifecycle/ that's trying to explain these browser-level restrictions, but there may be other documents involved. Wake Locks ought to override this, but you need to specify how. It's possible that a single "system" wake lock type isn't sufficient.
I am not sure if I understand your question completely here. Are you asking what will happen if there are multiple tabs requesting system wakelock and/or tabs requesting system wake lock are backgrounded? If you can clarify with examples that will be great.



Separately, I want to make sure that you're in contact with the security UI team, to make sure that the "system" wakelock gets the right permission UX, to prevent pages from surreptitiously mining bitcoin or tracking a user's location. What permission UX are you planning?
 This is a good point. The issue of permissions and how to handle them is actively being discussed here, https://github.com/w3c/wake-lock/issues/140. Wouldn't permissions for user's location fall under Geolocation settings though? Not sure how this is related to Wake Lock.


Thanks,
Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Jeffrey Yasskin

unread,
Dec 27, 2018, 3:31:02 PM12/27/18
to Reilly Grant, mrunal...@intel.com, blink-dev, Kostiainen, Anssi, bogdan...@yandex-team.ru, alog...@yandex-team.ru
On Wed, Dec 26, 2018 at 11:08 AM Reilly Grant <rei...@chromium.org> wrote:
On Fri, Dec 21, 2018 at 4:07 PM <mrunal...@intel.com> wrote:
On Tuesday, December 18, 2018 at 10:01:43 AM UTC-8, Jeffrey Yasskin wrote:
Sorry for missing this when you first sent it.

I'm concerned about the "system" wakelock type. It's specified to "prevents device's CPU from entering a standby mode so that the programs can continue running." However, this omits several relevant aspects of the web stack. I've filed some bugs against the spec, but I want to make sure the other informed folks on blink-dev know to point out anything I'm missing below.

* CPUs have all sorts of standby modes with different power needs and responsiveness levels. Does this wakelock require the CPU to be running at its top power mode continuously, even if the website is just waiting for, say, the user to change their location?
The Blink side of Wake Lock implementation relies on the mojo Wake Lock device service. At least Blink side implementation we are not manipulating the power mode directly and I don't think this will change in near future. 

* How many CPUs does the wakelock apply to in a device with multiple CPUs?
As I mentioned above since we use mojo Wake Lock device service we don't control how many CPUs or cores it apples the lock on.

We shouldn't think of a a Mojo service as something unknowable and unchanging. It is part of the Chromium source just as much as Blink is. We should understand what its capability are and if it needs to change to support an API implemented in Blink then it must change.

Exactly. And the API needs to be designed around the needs of people using the browser, not around what happens to be currently implemented in a Mojo service.

* There's a web browser sitting between the website and the CPU: even if the CPU is running full tilt, the browser may not deliver events to the website or give it any CPU time to execute. I know of https://wicg.github.io/page-lifecycle/ that's trying to explain these browser-level restrictions, but there may be other documents involved. Wake Locks ought to override this, but you need to specify how. It's possible that a single "system" wake lock type isn't sufficient.
 
I am not sure if I understand your question completely here. Are you asking what will happen if there are multiple tabs requesting system wakelock and/or tabs requesting system wake lock are backgrounded? If you can clarify with examples that will be great.

If a site is open, but it's not in the tab the user is actively looking at, the systems described at https://wicg.github.io/page-lifecycle/ can pause execution of that site, in order to free up resources for the site the user's actively using. If that site had a system wakelock, but the system wakelock only affects the device's CPU and not the browser (and that is the limited effect described by the current specification), then the site author's intent won't be achieved, and the user may be disappointed.

Separately, I want to make sure that you're in contact with the security UI team, to make sure that the "system" wakelock gets the right permission UX, to prevent pages from surreptitiously mining bitcoin or tracking a user's location. What permission UX are you planning?
 
 This is a good point. The issue of permissions and how to handle them is actively being discussed here, https://github.com/w3c/wake-lock/issues/140. Wouldn't permissions for user's location fall under Geolocation settings though? Not sure how this is related to Wake Lock.

Geolocation settings and its current permission UI handle the interaction of geolocation with existing ways that a page can execute and the limitations on that execution. If you're changing the limitations, it's up to you to make sure that the permission UI still works.

Jeffrey

Alex Russell

unread,
Jan 11, 2019, 3:27:25 PM1/11/19
to blink-dev, rei...@chromium.org, mrunal...@intel.com, anssi.ko...@intel.com, bogdan...@yandex-team.ru, alog...@yandex-team.ru
As a procedural question, I know there was a TAG review filed for an earlier iteration of the spec:

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

Has one been filed for this new iteration? I'm having trouble finding it.

I have some concerns about the model putting the responsibility for not losing the lock object onto the consumer. The failure case is pretty bad. Should there be a method that lets as consumer iterate over (and get references to) active lock objects?

Regards

Thomas Steiner

unread,
Jan 11, 2019, 6:01:35 PM1/11/19
to Alex Russell, Pete LePage, alog...@yandex-team.ru, anssi.ko...@intel.com, blink-dev, bogdan...@yandex-team.ru, mrunal...@intel.com, rei...@chromium.org
On Fri 11. Jan 2019 at 21:27 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:
As a procedural question, I know there was a TAG review filed for an earlier iteration of the spec:

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

Has one been filed for this new iteration? I'm having trouble finding it.

I have some concerns about the model putting the responsibility for not losing the lock object onto the consumer. The failure case is pretty bad. Should there be a method that lets as consumer iterate over (and get references to) active lock objects?

Pete LePage has filed 
https://github.com/w3c/wake-lock/issues/133 when this was brought up during the review rounds of his Wake Lock article. 



Regards

On Thursday, December 27, 2018 at 12:31:02 PM UTC-8, Jeffrey Yasskin wrote:

On Wed, Dec 26, 2018 at 11:08 AM Reilly Grant <rei...@chromium.org> wrote:
On Fri, Dec 21, 2018 at 4:07 PM <mrunal...@intel.com> wrote:
On Tuesday, December 18, 2018 at 10:01:43 AM UTC-8, Jeffrey Yasskin wrote:
Sorry for missing this when you first sent it.

I'm concerned about the "system" wakelock type. It's specified to "prevents device's CPU from entering a standby mode so that the programs can continue running." However, this omits several relevant aspects of the web stack. I've filed some bugs against the spec, but I want to make sure the other informed folks on blink-dev know to point out anything I'm missing below.

* CPUs have all sorts of standby modes with different power needs and responsiveness levels. Does this wakelock require the CPU to be running at its top power mode continuously, even if the website is just waiting for, say, the user to change their location?
The Blink side of Wake Lock implementation relies on the mojo Wake Lock device service. At least Blink side implementation we are not manipulating the power mode directly and I don't think this will change in near future. 

* How many CPUs does the wakelock apply to in a device with multiple CPUs?
As I mentioned above since we use mojo Wake Lock device service we don't control how many CPUs or cores it apples the lock on.

We shouldn't think of a a Mojo service as something unknowable and unchanging. It is part of the Chromium source just as much as Blink is. We should understand what its capability are and if it needs to change to support an API implemented in Blink then it must change.

Exactly. And the API needs to be designed around the needs of people using the browser, not around what happens to be currently implemented in a Mojo service.

* There's a web browser sitting between the website and the CPU: even if the CPU is running full tilt, the browser may not deliver events to the website or give it any CPU time to execute. I know of https://wicg.github.io/page-lifecycle/ that's trying to explain these browser-level restrictions, but there may be other documents involved. Wake Locks ought to override this, but you need to specify how. It's possible that a single "system" wake lock type isn't sufficient.
 
I am not sure if I understand your question completely here. Are you asking what will happen if there are multiple tabs requesting system wakelock and/or tabs requesting system wake lock are backgrounded? If you can clarify with examples that will be great.

If a site is open, but it's not in the tab the user is actively looking at, the systems described at https://wicg.github.io/page-lifecycle/ can pause execution of that site, in order to free up resources for the site the user's actively using. If that site had a system wakelock, but the system wakelock only affects the device's CPU and not the browser (and that is the limited effect described by the current specification), then the site author's intent won't be achieved, and the user may be disappointed.

Separately, I want to make sure that you're in contact with the security UI team, to make sure that the "system" wakelock gets the right permission UX, to prevent pages from surreptitiously mining bitcoin or tracking a user's location. What permission UX are you planning?
 
 This is a good point. The issue of permissions and how to handle them is actively being discussed here, https://github.com/w3c/wake-lock/issues/140. Wouldn't permissions for user's location fall under Geolocation settings though? Not sure how this is related to Wake Lock.

Geolocation settings and its current permission UI handle the interaction of geolocation with existing ways that a page can execute and the limitations on that execution. If you're changing the limitations, it's up to you to make sure that the permission UI still works.

Jeffrey

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

Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages