Intent to Experiment: Screen Wake Lock API

[Reilly Grant]

Contact emails

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

Spec

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

Summary

This API allows a site to prevent the system from automatically locking or powering off the display. To make this request the page must be already be visible and the user can override the lock by switching to another tab or manually locking or powering off their display.

This is a subset of the full Wake Lock API.

Link to “Intent to Implement” blink-dev discussion

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

TAG reviews

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

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

Goals for experimentation

We are looking for feedback from developers on the shape of the API and whether the “screen wake lock” subset of the full specification is sufficient for their use cases.

Experimental timeline

Chrome 78 to 80. We have at least one partner lined up with code that can be deployed to experiment with this feature.

Any risks when the experiment finishes?

Sites will lose the ability to keep the screen awake which may cause a regression in user experience.

Ongoing technical constraints

None.

Debuggability

DevTools support isn’t necessary for debugging code that uses this feature. Such support could be added later, for example, showing active locks held by a page.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/4636879949398016

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

[Yoav Weiss]

Does the experiment also include user permissions/notifications regarding the fact that the site keeps their screen from sleeping as long as it's in the foreground? 

--
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/CAEmk%3DMajxLBgGd8_-TtJ766Mq4rdfpsWGEdH4JgTGaWPoM%2B9dw%40mail.gmail.com.

[Reilly Grant]

On Wed, Sep 11, 2019 at 4:15 PM Yoav Weiss <yo...@yoav.ws> wrote:

Does the experiment also include user permissions/notifications regarding the fact that the site keeps their screen from sleeping as long as it's in the foreground?

This subset of the API has no permission because the restrictions that the page is already visible and that the user can override the lock seem to mitigate potential abuse. The API is its own usage indicator because it keeps the screen on.

[Yoav Weiss]

LGTM to experiment, even if I have more questions regarding the user-visible aspects of this.

On Wed, Sep 11, 2019 at 10:17 AM Reilly Grant <rei...@chromium.org> wrote:

On Wed, Sep 11, 2019 at 4:15 PM Yoav Weiss <yo...@yoav.ws> wrote:

Does the experiment also include user permissions/notifications regarding the fact that the site keeps their screen from sleeping as long as it's in the foreground?

This subset of the API has no permission because the restrictions that the page is already visible and that the user can override the lock seem to mitigate potential abuse. The API is its own usage indicator because it keeps the screen on.

OK, so no permissions, but is there a user notification telling the user "this page is special and keeps your device awake as long as you're looking at it"?

Do we have any ways to gauge the user's reaction to the feature? e.g. are we planning to count "user override"? Bounce rates?

[Jonny Powell]

Does this not go against precedent set by, for example, the Fullscreen API, which is arguably more apparent to the user, but will still notify the user that fullscreen mode was entered?

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

[Reilly Grant]

On Wed, Sep 11, 2019 at 9:10 PM Jonny Powell <jonnyow...@gmail.com> wrote:

Does this not go against precedent set by, for example, the Fullscreen API, which is arguably more apparent to the user, but will still notify the user that fullscreen mode was entered?

The threat model for the Fullscreen API that leads to that notification is the concern that the site can take advantage of being full screen to spoof trusted Chrome or system UI, and that the user will not know how to exit from full screen. That doesn't apply here because users already know how to put their devices to sleep. 

[Reilly Grant]

On Wed, Sep 11, 2019 at 9:15 PM Yoav Weiss <yo...@yoav.ws> wrote:

LGTM to experiment, even if I have more questions regarding the user-visible aspects of this.

On Wed, Sep 11, 2019 at 10:17 AM Reilly Grant <rei...@chromium.org> wrote:

On Wed, Sep 11, 2019 at 4:15 PM Yoav Weiss <yo...@yoav.ws> wrote:

Does the experiment also include user permissions/notifications regarding the fact that the site keeps their screen from sleeping as long as it's in the foreground?

This subset of the API has no permission because the restrictions that the page is already visible and that the user can override the lock seem to mitigate potential abuse. The API is its own usage indicator because it keeps the screen on.

OK, so no permissions, but is there a user notification telling the user "this page is special and keeps your device awake as long as you're looking at it"?

There is currently no such notification. The feedback from Chrome Security review was that this wasn't necessary. It is something we can look into if we observe abuse.

Do we have any ways to gauge the user's reaction to the feature? e.g. are we planning to count "user override"? Bounce rates?

We can add a metric to measure the reasons why the wake lock is revoked, user switching focus, closing the tab, or voluntarily by the application. I'm not sure at this point how to derive user intent from that signal.

[Reilly Grant]

This Origin Trial was delayed until the issues raised on w3c/wake-lock#226 could be discussed at TPAC. The API changes have been implemented and so I have updated the experimental timeline below.

On Tue, Sep 10, 2019 at 11:14 PM Reilly Grant <rei...@chromium.org> wrote:

Contact emails

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

Spec

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

Summary

This API allows a site to prevent the system from automatically locking or powering off the display. To make this request the page must be already be visible and the user can override the lock by switching to another tab or manually locking or powering off their display.

This is a subset of the full Wake Lock API.

Link to “Intent to Implement” blink-dev discussion

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

TAG reviews

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

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

Goals for experimentation

We are looking for feedback from developers on the shape of the API and whether the “screen wake lock” subset of the full specification is sufficient for their use cases.

Experimental timeline (updated)

Chrome 79 to 81. We have at least one partner lined up with code that can be deployed to experiment with this feature.