Intent to Extend Origin Trial: Web Locks API

[Victor Costan]

Contact emails

jsb...@chromium.org, pwn...@chromium.org

Explainer

https://github.com/inexorabletash/web-locks

Spec

https://inexorabletash.github.io/web-locks/

Summary

A new web platform primitive API that allows parts of a web app running in different tabs/workers to coordinate use of abstract shared resources. This is equivalent to a "mutex" as exposed by many operating systems, with additional optional lock types (exclusive and shared) for common database/filesystem scenarios.

navigator.locks.request("my_resource", async lock => {

  // can assert that no other tab/worker in this origin

  // is using "my_resource" until this async function completes

});

An Origin Trial for Web Locks started in Chrome 66 and is scheduled to end in Chrome 67. The API was approved to ship in Chrome 69. The Origin Trials have revealed bugs, but the API will not be changing its shape.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/apdn-NbyZJg/discussion

"Intent to Ship" discussion: 

https://groups.google.com/a/chromium.org/d/topic/blink-dev/e2fg_-Ha-AE/discussion

Goals for experimentation

G Suite has rolled out the Web Locks API to a percentage of the user base. These users are seeing a 10x reduction in locking errors compared to a control group that uses a pure-JavaScript locking solution. Given these significant user benefits, we would like to extend the Origin Trial for Web Locks throughout Chrome 68.

Experimental timeline

We would like to keep Web Locks in Origin Trials in M68, and transition to general availability in M69. The intent to ship in M69 has already been approved.

Any risks when the experiment finishes?

G Suite is prepared to fall back to the pure-JavaScript solution should the Web Locks API become unavailable for any reason, but that would result in a degraded user experience, as the 10x error reduction benefit would go away.

Reason this experiment is being extended

This feature results in significant user experience benefits on a major Web property.

Ongoing technical constraints

None

Debuggability

Lock state can be queried via navigator.locks.query() to get a snapshot of lock state. A feature request (from the Google Docs/Sheets/Slides team) would improve this further with application-specific metadata; that can be added in the future without breaking API changes.

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://www.chromestatus.com/feature/5712361335816192

[Chris Harrelson]

LGTM

Argument why this is ok: in this case we have an Origin Trial that has been deemed a success, and the feature is shipping in exactly the same form in the next Chrome release. In this case it does not seem harmful to allow early adopters to keep using the feature in the meantime.

Perhaps we should adjust the policy for Origin Trials to take this situation into account. This is not the first time this situation has come up.

--
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/CAP_mGKrEFLomRB%3DwynZ2Ndt3EBuKjjrecE5g-Y6tWA%2B_gv3UxQ%40mail.gmail.com.