Intent to Prototype and Ship: WakeLockSentinel.released attribute

Raphael Kubo Da Costa

unread,

Sep 1, 2020, 5:23:46 AM9/1/20

to blink-dev

Contact emails

raphael.ku...@intel.com, rei...@chromium.org

Summary

The read-only “released” attribute in the WakeLockSentinel object allows web developers to know whether a given lock has already been released. The same thing can already be done manually by monitoring the "onrelease" event, so the new attribute had been added simply to make things easier for developers following the discussion in https://github.com/w3c/screen-wake-lock/issues/272.

Spec

https://w3c.github.io/screen-wake-lock/#the-released-attribute and https://github.com/w3c/screen-wake-lock/pull/279.

The TAG wasn't asked to review this minor change specifically, but the whole spec's currently under TAG review in https://github.com/w3ctag/design-reviews/issues/543.

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

Yes.

Risks

Interoperability and Compatibility

The interoperability risk is no higher than before: Mozilla is interested in implementing the API but hasn't done it yet, Apple is not part of the Devices & Sensors WG. The idea and the spec change were reviewed by Mozilla.

Signals from other implementations (Gecko, WebKit):

Gecko: The Screen Wake Lock API is deemed “worth prototyping”. As mentioned, Mozilla was active in reviewing this change to the spec.
WebKit: No Signal when it comes to implementing this entire API.

Web / Framework developers: The request for the new attribute came from a web developer’s perspective, so I would say positive.

Ergonomics

No special considerations. A single read-only attribute is being added.

Activation

No special considerations. Developers can already achieve what this new attribute indicates, albeit with a bit more work.

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

Yes. I'm adding some tests in https://github.com/web-platform-tests/wpt/pull/25271 and extending some Blink ones in https://chromium-review.googlesource.com/c/chromium/src/+/2379740.

Entry on the feature dashboard

https://chromestatus.com/feature/5632527123349504

Yoav Weiss

unread,

Sep 1, 2020, 8:46:00 AM9/1/20

to Raphael Kubo Da Costa, blink-dev

On Tue, Sep 1, 2020 at 11:23 AM Raphael Kubo Da Costa <raphael.ku...@intel.com> wrote:

Contact emails
raphael.ku...@intel.com, rei...@chromium.org

Summary
The read-only “released” attribute in the WakeLockSentinel object allows web developers to know whether a given lock has already been released. The same thing can already be done manually by monitoring the "onrelease" event, so the new attribute had been added simply to make things easier for developers following the discussion in https://github.com/w3c/screen-wake-lock/issues/272.

It would be good to add a few lines explaining what is the role of this attribute, how we expect developers to use it, etc.

An "inline explainer" if you will.

Spec
https://w3c.github.io/screen-wake-lock/#the-released-attribute and https://github.com/w3c/screen-wake-lock/pull/279.
The TAG wasn't asked to review this minor change specifically, but the whole spec's currently under TAG review in https://github.com/w3ctag/design-reviews/issues/543.

Seems like this is the third TAG review (after #32 and #126). Did the spec change significantly between the reviews?

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

Risks
Interoperability and Compatibility
The interoperability risk is no higher than before: Mozilla is interested in implementing the API but hasn't done it yet, Apple is not part of the Devices & Sensors WG. The idea and the spec change were reviewed by Mozilla.
Signals from other implementations (Gecko, WebKit):
Gecko: The Screen Wake Lock API is deemed “worth prototyping”. As mentioned, Mozilla was active in reviewing this change to the spec.
WebKit: No Signal when it comes to implementing this entire API.
Web / Framework developers: The request for the new attribute came from a web developer’s perspective, so I would say positive.
Ergonomics
No special considerations. A single read-only attribute is being added.
Activation
No special considerations. Developers can already achieve what this new attribute indicates, albeit with a bit more work.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes. I'm adding some tests in https://github.com/web-platform-tests/wpt/pull/25271 and extending some Blink ones in https://chromium-review.googlesource.com/c/chromium/src/+/2379740.

Entry on the feature dashboard
https://chromestatus.com/feature/5632527123349504

--
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/48cae29d-b95b-4e49-ad68-16106c577c36n%40chromium.org.

Raphael Kubo Da Costa

unread,

Sep 1, 2020, 9:36:39 AM9/1/20

to blink-dev, yo...@yoav.ws

On Tuesday, 1 September 2020 at 14:46:00 UTC+2 yo...@yoav.ws wrote:

On Tue, Sep 1, 2020 at 11:23 AM Raphael Kubo Da Costa <raphael.ku...@intel.com> wrote:
Contact emails
raphael.ku...@intel.com, rei...@chromium.org

Summary
The read-only “released” attribute in the WakeLockSentinel object allows web developers to know whether a given lock has already been released. The same thing can already be done manually by monitoring the "onrelease" event, so the new attribute had been added simply to make things easier for developers following the discussion in https://github.com/w3c/screen-wake-lock/issues/272.

It would be good to add a few lines explaining what is the role of this attribute, how we expect developers to use it, etc.
An "inline explainer" if you will.

The idea in the GitHub issue above involved multiple locks, but essentially the idea is to allow developers to query a lock's state from lock object itself, rather than having to keep track of the state externally. In other words, one can do this:

button.addEventListener('click', () => {

checkbox.checked = lockSentinel.released;

});

rather than

let lockReleased = false;

lockSentinel.addEventListener('release', () => {

lockReleased = true;

});

button.addEventListener('click', () => {

checkbox.checked = lockReleased;

});

Spec
https://w3c.github.io/screen-wake-lock/#the-released-attribute and https://github.com/w3c/screen-wake-lock/pull/279.
The TAG wasn't asked to review this minor change specifically, but the whole spec's currently under TAG review in https://github.com/w3ctag/design-reviews/issues/543.

Seems like this is the third TAG review (after #32 and #126). Did the spec change significantly between the reviews?

Yes. #126 seems to be from 2016. Since then, the spec's editors changed, and the API changed quite significantly. FWIW, it's this new spec iteration that we've been shipping since M84.

Chris Harrelson

unread,

Sep 3, 2020, 3:26:19 PM9/3/20

to Raphael Kubo Da Costa, blink-dev

On Tue, Sep 1, 2020 at 2:23 AM Raphael Kubo Da Costa <raphael.ku...@intel.com> wrote:

Contact emails
raphael.ku...@intel.com, rei...@chromium.org

Summary
The read-only “released” attribute in the WakeLockSentinel object allows web developers to know whether a given lock has already been released. The same thing can already be done manually by monitoring the "onrelease" event, so the new attribute had been added simply to make things easier for developers following the discussion in https://github.com/w3c/screen-wake-lock/issues/272.

Spec
https://w3c.github.io/screen-wake-lock/#the-released-attribute and https://github.com/w3c/screen-wake-lock/pull/279.
The TAG wasn't asked to review this minor change specifically, but the whole spec's currently under TAG review in https://github.com/w3ctag/design-reviews/issues/543.

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

Risks
Interoperability and Compatibility
The interoperability risk is no higher than before: Mozilla is interested in implementing the API but hasn't done it yet, Apple is not part of the Devices & Sensors WG. The idea and the spec change were reviewed by Mozilla.
Signals from other implementations (Gecko, WebKit):
Gecko: The Screen Wake Lock API is deemed “worth prototyping”. As mentioned, Mozilla was active in reviewing this change to the spec.
WebKit: No Signal when it comes to implementing this entire API.

Could you ask them for an explicit signal, according to the current process (i.e. email webkit-dev about the Wake Lock API)?

Web / Framework developers: The request for the new attribute came from a web developer’s perspective, so I would say positive.
Ergonomics
No special considerations. A single read-only attribute is being added.
Activation
No special considerations. Developers can already achieve what this new attribute indicates, albeit with a bit more work.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes. I'm adding some tests in https://github.com/web-platform-tests/wpt/pull/25271 and extending some Blink ones in https://chromium-review.googlesource.com/c/chromium/src/+/2379740.

Entry on the feature dashboard
https://chromestatus.com/feature/5632527123349504

sligh...@chromium.org

unread,

Sep 3, 2020, 3:27:58 PM9/3/20

to blink-dev, raphael.ku...@intel.com

LGTM1

On Thursday, September 3, 2020 at 12:26:19 PM UTC-7, Chris Harrelson wrote:

On Tue, Sep 1, 2020 at 2:23 AM Raphael Kubo Da Costa <raphael.kubo.da.costa@intel.com> wrote:
Contact emails
raphael.kubo.da.costa@intel.com, rei...@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Manuel Rego Casasnovas

unread,

Sep 3, 2020, 3:31:00 PM9/3/20

to Chris Harrelson, Raphael Kubo Da Costa, blink-dev

On 03/09/2020 21:26, Chris Harrelson wrote:
> *
>
> WebKit: No Signal
> <https://bugs.webkit.org/show_bug.cgi?id=205104> when it comes

> to implementing this entire API.
>
> Could you ask them for an explicit signal, according to the current
> process (i.e. email webkit-dev about the Wake Lock API)?

There was a thread early this year on webkit-dev but it looks like Apple
position was not a final one yet, so it might be worth re-pinging the
thread:
https://lists.webkit.org/pipermail/webkit-dev/2020-February/031081.html

Bye,
Rego

Raphael Kubo Da Costa

unread,

Sep 3, 2020, 3:58:19 PM9/3/20

to blink-dev

Thanks, I was still looking for the right thread there.

Thomas pinged the WebKit folks back in December 2019, and as you mentioned nothing's happened after Thomas' response to Ryosuke's message.

Daniel Bratell

unread,

Sep 3, 2020, 4:04:11 PM9/3/20

to Raphael Kubo Da Costa, blink-dev

LGTM2

/Daniel

--
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/7f8f70a7-7cd9-4262-a426-9dc531e26be4n%40chromium.org.

Yoav Weiss

unread,

Sep 3, 2020, 4:10:54 PM9/3/20

to Daniel Bratell, Raphael Kubo Da Costa, blink-dev

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/da3332f0-c9e7-2b6c-1e57-95ef1504e347%40gmail.com.

Reply all

Reply to author

Forward