Intent to Prototype and Ship: WakeLockSentinel.released attribute

95 views
Skip to first unread message

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.

Yoav Weiss

unread,
Sep 3, 2020, 4:10:54 PM9/3/20
to Daniel Bratell, Raphael Kubo Da Costa, blink-dev
Reply all
Reply to author
Forward
0 new messages