That's a good point. I'm in touch with the Android/Chrome team about the underlying issue.

I was hoping the underlying Android web issue would have been fixed by now (as I first noticed it ~3 years ago with some indication for progress), but looks like LiveStore needs a custom workaround for it. You can track the progress here: https://github.com/livestorejs/livestore/issues/321

I hope you understand that bridging the gaps between various levels of supported web APIs take a lot of effort and is non-trivial when building ambitious systems like LiveStore.

It’s beyond shameful that chrome on android doesn’t support shared workers yet. We decided to simply nix multi tab support on android because of it.

I’ve been working on a very similar sync problem and hit this too. I think the way forward is to use a broadcast channel to elect an individual worker that communicates with all other contexts using the broadcast channel.

fyi, I've done something similar and the cleanest method for leader election is to use the web locks api:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A...

It is supported by all browsers. You just have all the tabs try to lock the same resource and have them return a promise in the lock callback. The first one wins and when that tab closes the next one in line gets automatically elected.

The leader can then use a broadcast channel and act as a server for all the other tabs to serialize access to any shared resources.

That’s very elegant, thanks!

Very interesting context. Thank you for sharing.