RxDB with lokijs works bad in Safari and FF when using multiple tabs

[11bit]

RxDB with LokiJS adapter seems to be not working well in FF and Safari in non-leader tab when multiple tabs are opened.

Firefox v97
When I open two tabs, changes in the first tab happen very quickly however in the second tab it takes 500-1000ms to propogate. This is most likely due to cpu throttliing for the background tab (which happens to be a leader) because if i open two windows side by side, then everything works very quickly

Safari Version 15.2
In the first tab everything works ok. In the second tab after a couple of changes, change listener starts firing infinitely

Repo with bug reproduction
Demo https://peaceful-haibt-3425a9.netlify.app

[swnf]

I tried this in Firefox 96. It think this happens because of the promiseWait(0) calls which use setTimeout (which is throttled). If I change promiseWait(0) to resolve immediately, there is no significant delay in the non-leader tab. Maybe there is some alternative to setTimeout(..., 0)? It seems like promises already have some guarantees about asynchronicity. There is a setImmediate polyfill on mdn which might work.

[pubkey]

@swnf this makes sense.
I think we can just remove the promiseWait(0). They are not really needed, I just thought it simulates similar behavior then the other storages and some tests failed without them.

[swnf]

Well it does certainly make sense to ensure an async method never completes in sync (just google "releasing Zalgo"). However, this pattern came from the callback era. If I understand the MDN article correctly, the promiseWait(0) should not be necessary in your case because you are using a method marked as async. The onFulfilled handler of the returned promise will never be called in sync. So the behavior should already be consistent. It is weird that the tests behave differently.

[pubkey]

Trying to fix this by not longer using setTimeout in the LokiJS RxStorage internals.
#3672

[pubkey]

Merged this now. Please test again on the next release.

[11bit]

@pubkey Thanks for fixing. Issue in firefox is resolved!

It's still slow in Safari though (up to 100-200ms). But I think the problem is different and likely related to broadcast channel, because if I set enforceOptions({type: 'localstorage'}) then it works much faster

[pubkey]

@11bit you should not enfore localstorage type because then it will not use the native BroadcastChannel if available. Instead you should enforce webWorkerSupport: false so that it prefers the localstorage method instead of the indexeddb method.

enforceOptions({webWorkerSupport: false})