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,
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.
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/E2844C62-5262-4D2D-9102-68B2101DD9A6%40intel.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?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7769f788-dc4b-475c-928a-f15b0bdf9c16%40chromium.org.
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
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
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/33157074-b300-427a-821b-794edf7d5a51%40chromium.org.
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.
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
On Thursday, December 27, 2018 at 12:31:02 PM UTC-8, Jeffrey Yasskin wrote:+ the spec editors too. (https://groups.google.com/a/chromium.org/d/topic/blink-dev/KMNZmMF1_H4/discussion)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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dcc0ce80-16ff-4237-9fac-08c3a16e1c6c%40chromium.org.