[schickling]

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.

[autoconfig]

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.

[wlib]

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.

[dugmartin]

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.

[wlib]

That’s very elegant, thanks!

[growthwtf]

Very interesting context. Thank you for sharing.