Contact emails
jsb...@chromium.org, pwn...@chromium.org (but I still blame darin@)
Explainer
https://github.com/inexorabletash/web-locks
Spec
https://inexorabletash.github.io/web-locks/
(Proposed to move to WICG, waiting on interest from others)
TAG Review:
https://github.com/w3ctag/design-reviews/issues/217 then
https://github.com/inexorabletash/web-locks/issues/35
Summary
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/DpODIjdpUMg/hVQkjqeIAAAJLink to Origin Trial feedback summary
Feedback from Google Docs/Sheets/Slides:
Chrome implemented a Web Locks API to provide support for an authoritative lock management system. Early data from a Docs/Sheets/Slides experiment using Web Locks through Chrome’s origin trial showed that lock related errors were reduced by 10x.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
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.
Risks
Interoperability and Compatibility
The proposal has been reviewed by the TAG, but no other browsers have given an assessment on design or implementation challenges.
Edge: No signals
Firefox: No signals; discussion raised by Marcos Cáceres at https://github.com/mozilla/standards-positions/issues/64 (after highlighting important issues about the specifics of how locks are scoped to browsing sessions, the discussion veered into details of Safari dual-keyed storage behavior and hasn't had follow-up)
Safari: No signals
Web developers: As noted, at least one Google team is strongly positive. Otherwise, feedback has been extremely sparse.
Ergonomics
The API shape was arrived at after significant exploration (see the history of the git repo) to arrive at an API that avoids pitfalls while still allowing full programmatic control of lock lifetime; the TAG walked through this again, arriving at the same conclusion.
Web applications can "deadlock" themselves with respect to this API (e.g. holding a lock and never releasing it) but no other capability is tied to these abstract locks, so any risk for the app is opt-in. Locks also do not span origins or browsing sessions, and there are no known performance implications for other APIs although some of the lock management algorithms could be improved.
Activation
The API would benefit from documentation on MDN. The spec has many examples, but more would not hurt.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
I believe the Firefox status at the moment is that we're not clear on
exactly what the proposed scoping is in various important cases, which
is making it hard to evaluate whether it makes sense, which is making it
hard to decide what we think about the proposal. Which is why there's
been no followup on our standards position; we don't have enough
information to evaluate.
I will say that I personally am extremely concerned about too-broad
scoping getting baked into the implementation and consumers and hence
making it difficult to ship other features in the future, change process
models, improve user privacy via efforts like Firefox's containers, etc.
To give a simple example,
https://inexorabletash.github.io/web-locks/#security-scope seems to
assume that the set of partitions is the same for all "storage
facilities" and "communication channels", which may well not be true in
general, depending on a UA's actual goals.
On Thu, Jun 28, 2018 at 11:39 AM Boris Zbarsky <bzba...@mit.edu> wrote:I believe the Firefox status at the moment is that we're not clear on
exactly what the proposed scoping is in various important cases, which
is making it hard to evaluate whether it makes sense, which is making it
hard to decide what we think about the proposal. Which is why there's
been no followup on our standards position; we don't have enough
information to evaluate.Are you able to enumerate those cases with respect to the proposal?I will say that I personally am extremely concerned about too-broad
scoping getting baked into the implementation and consumers and hence
making it difficult to ship other features in the future, change process
models, improve user privacy via efforts like Firefox's containers, etc.Do you have suggestions for defining the scope in a way that captures the use cases but does not constrain future features?A common use case is that, for example, if two tabs are editing the same "document" only one should be doing network<->storage synchronization. I would therefore be fine with equating lock scope with storage scope, although there are of course use cases that don't require the use of storage.
On Thu, Jun 28, 2018 at 11:44 AM Boris Zbarsky <bzba...@mit.edu> wrote:To give a simple example,
https://inexorabletash.github.io/web-locks/#security-scope seems to
assume that the set of partitions is the same for all "storage
facilities" and "communication channels", which may well not be true in
general, depending on a UA's actual goals.Noted. To the best of my knowledge, the correspondence is true in Chrome today - that is, if code within an origin writes to a storage API like Indexed DB, or Cache API, then announces this using BroadcastChannel, all recipients of the message would agree that storage has been modified. Web apps may already be making that assumption; I don't believe we've properly defined scoping for either storage or communication in the platform, nor relative to one another.
--
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/CAD649j4azFtRYiXfLP%3Dj-4RHBaJS2%2BUd8tRwfQ-iRX1SO85exA%40mail.gmail.com.
Based on a conversation earlier today with, it seems that my concern
boils down to this. The proposal is for abstract locks which are not
tied to particular features. This has obvious desirable qualities, but
requires that the lock scope match the scope of whatever you're locking.
And since you don't know what you're locking, the scopes of all the
things need to match.
So it's possible that the right answer is to be more explicit about what
you plan to lock with a given lock so that it can be scoped appropriately.
> Noted. To the best of my knowledge, the correspondence is true in Chrome
> today
Except cookies, right?
Ben Kelly pointed out that BroadcastChannel already has this problem to
some extent, in that you could try to build a synchronization setup on
top of it. Which is true, but it's a lot easier to write off failures
of that to correspond to storage scoping as "yeah, we don't guarantee
that" than it would be with web locks, which are explicitly meant to
guarantee things work right.
-Boris
[1] Let me give a concrete example.
On Thu, Jun 28, 2018 at 1:10 PM Boris Zbarsky <bzba...@mit.edu> wrote:Based on a conversation earlier today with, it seems that my concern
boils down to this. The proposal is for abstract locks which are not
tied to particular features. This has obvious desirable qualities, but
requires that the lock scope match the scope of whatever you're locking.
And since you don't know what you're locking, the scopes of all the
things need to match.
So it's possible that the right answer is to be more explicit about what
you plan to lock with a given lock so that it can be scoped appropriately.To make this concrete: this makes me think of adding a future option such as {lockScope: "storage"}, {lockScope: "communication"}, {lockScope: "agentcluster"} or {lockScope:"cookies"}. (Although the latter would almost certainly not be desirable.)
But I get your point, which is that without any definition here we wouldn't be able to provide guidance on when to use what, and there would be reluctance to provide any definition without constraining future evolution.> Noted. To the best of my knowledge, the correspondence is true in Chrome
> today
Except cookies, right?*sigh* Yes, except cookies.
Ben Kelly pointed out that BroadcastChannel already has this problem to
some extent, in that you could try to build a synchronization setup on
top of it. Which is true, but it's a lot easier to write off failures
of that to correspond to storage scoping as "yeah, we don't guarantee
that" than it would be with web locks, which are explicitly meant to
guarantee things work right.SharedWorker is another example. I'm not sure I'd write off web apps breakage as "we didn't guarantee that", but agreed that it's unclear if we have web compatibility constraints in this space already or not. But I hear your concern that this API would be forcing the issue.ISTM that implicitly scoping this feature to (non-cookie) storage preserves the usability we want, and there are paths to allow the same primitive to be used if more scopes can be properly defined in the future.
On 6/28/18 1:49 PM, Joshua Bell wrote:
> ISTM that implicitly scoping this feature to (non-cookie) storage
> preserves the usability we want, and there are paths to allow the same
> primitive to be used if more scopes can be properly defined in the future.
That seems OK to me if we're very certain that all non-cookie storage is
scoped in a consistent-with-each-other way in browsers. Which seems
like a reasonable thing to want, though I very much doubt any specs
actually come out and say it.
This spec would definitely want to explicitly say that's what the
scoping is.
--
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/CAD649j4yGGBUiYWdH5o_xH3QTeSPg7rA0%3D9rKt--D-8o13jAvg%40mail.gmail.com.
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/CAFUtAY89o3qTezegKjym0ZdRLrhpPyxOXL95EyarRyE_648%3DTg%40mail.gmail.com.