Skip to content

Cross-browser locks with a ServiceWorker #24

rhashimoto started this conversation in Show and tell
Cross-browser locks with a ServiceWorker #24
May 30, 2021 · 3 comments · 1 reply

Safari doesn't support the Web Locks API, and while you might be able to implement some form of synchronization with IndexedDB or even localStorage, a store-based approach by itself will have trouble with orphaned locks. At the moment the best cross-browser approach looks to be ServiceWorker.

ServiceWorker has its own quirks but I did get a proof-of-concept implementation working with an online demo. I didn't wrap it all up into a library because (1) I wanted to expose how it works, and (2) I don't need it for any current project.

Replies

3 comments
·
1 reply

I'm not 100% sure what you're accomplishing here, but did you also try SharedWorker()?
Also, you know you can create a MessageChannel() and pass the ports of the message channel between threads (not sure if that works between workers of different tabs), then you could pass messages directly between any workers of the same origin

1 reply
@rhashimoto

rhashimoto May 30, 2021
Maintainer Author

The use case is for anything you would use the Web Locks API for if it worked on all the browsers, e.g. implementing xLock and xUnlock in a IndexedDB VFS. If your web page uses a single SQLite database backed by IndexedDB and your user might have multiple windows or workers active on it, you need locking to make concurrent access safe.

I don't believe MessageChannel is a good general way to communicate across contexts (let alone synchronize), because in order to bootstrap the messaging from one Window to another Window I think that one has to open the other (e.g. via Window.open or iframe). It doesn't handle the case where a user just opens two tabs. It's really best at communication within one instance of a web app.

In fact, there aren't a lot of good ways for independent contexts to rendezvous, even though they belong to the same origin. BroadcastChannel and SharedWorker don't work on Safari. Extensions don't work on Safari, or on mobile. localStorage and IndexedDB do work, but aren't great for this use case. Using a server works, but you need a server and it has network latency. ServiceWorker really seems to be the best option if browser support is important.

rhashimoto
Jan 7, 2022
Maintainer Author

Safari added the Web Locks API in its Technology Preview release 137 (12/20/21). The release notes only mention the changeset for the initial single-process implementation but I think the changeset range includes the full implementation (see r286455 and r286514). Hopefully this will reach the main release soon.

0 replies

Safari 15.4 now supports the Web Locks API, BUT... it looks like some new features, including Web Locks and Origin Private File System, are only enabled for macOS 12 (Monterey) and not macOS 11 (Big Sur). Another long-awaited feature in 15.4, BroadcastChannel, is available on Big Sur, so perhaps Web Locks needs some Monterey operating system feature.

That's a little disappointing. Monterey was released in October 2021. Unfortunately, Apple stopped updating macOS version in the Safari user agent so public market share metrics can't provide a breakdown. Looking at an older transition, macOS 10 (Catalina) reached 65.81% at 13 months when Big Sur was released, and Catalina + Big Sur reached 80% after 24 months.

0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants