Use web worker when shared worker are not available #36
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Comlink API has a slight difference whether it is run in web worker or shared worker context.
SharedWorker are not available everywhere: https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker#browser_compatibility It is typically not available at this moment on android mobile chrome and opera, causing a blank screen for apps using the DataProxy on those browsers. Hence, we fallback on traditional web worker for such situation.
We force remote data, i.e. StackLink when using web worker, as it looks less necessary / CPU consuming in non-shared workers, which happen for old browsers and/or mobile browser
rezk2ll
approved these changes
Aug 25, 2025
Crash--
approved these changes
Aug 25, 2025
paultranvan
added a commit
to cozy/cozy-libs
that referenced
this pull request
Aug 28, 2025
Previously, the rendering of `DataProxyProvider` children were conditioned by the initialization of the dataproxy. It was because we wanted to avoid timing issues, were the App started to use the DataProxy before it was actually ready. See https://github.com/cozy/cozy-libs/commit/ bdb1670 We later made it less strict, because if anything make the dataproxy not initialized, nothing is displayed on the app side with no logs, making it hard to debug for the developer. See #2801 However, we still met situations with no rendering, because the dataproxy was not available at all: - Public sharing: cozy/cozy-drive#3439 - Unsupported shared workers: cozy/cozy-web-data-proxy#36 So now, we always render children, and expect the `DataProxyLink` to handle queries made on non-ready DataProxy by queuing them: cozy/cozy-client#1622
paultranvan
added a commit
to cozy/cozy-libs
that referenced
this pull request
Aug 28, 2025
Previously, the rendering of `DataProxyProvider` children were conditioned by the initialization of the dataproxy. It was because we wanted to avoid timing issues, were the App started to use the DataProxy before it was actually ready. See https://github.com/cozy/cozy-libs/commit/ bdb1670 We later made it less strict, because if anything make the dataproxy not initialized, nothing is displayed on the app side with no logs, making it hard to debug for the developer. See #2801 However, we still met situations with no rendering, because the dataproxy was not available at all: - Public sharing: cozy/cozy-drive#3439 - Unsupported shared workers: cozy/cozy-web-data-proxy#36 So now, we always render children, and expect the `DataProxyLink` to handle queries made on non-ready DataProxy by queuing them: cozy/cozy-client#1622
paultranvan
added a commit
to cozy/cozy-libs
that referenced
this pull request
Sep 19, 2025
Previously, the rendering of `DataProxyProvider` children were conditioned by the initialization of the dataproxy. It was because we wanted to avoid timing issues, were the App started to use the DataProxy before it was actually ready. See https://github.com/cozy/cozy-libs/commit/ bdb1670 We later made it less strict, because if anything make the dataproxy not initialized, nothing is displayed on the app side with no logs, making it hard to debug for the developer. See #2801 However, we still met situations with no rendering, because the dataproxy was not available at all: - Public sharing: cozy/cozy-drive#3439 - Unsupported shared workers: cozy/cozy-web-data-proxy#36 So now, we always render children, and expect the `DataProxyLink` to handle queries made on non-ready DataProxy by queuing them: cozy/cozy-client#1622
rezk2ll
pushed a commit
to cozy/cozy-libs
that referenced
this pull request
Sep 19, 2025
Previously, the rendering of `DataProxyProvider` children were conditioned by the initialization of the dataproxy. It was because we wanted to avoid timing issues, were the App started to use the DataProxy before it was actually ready. See https://github.com/cozy/cozy-libs/commit/ bdb1670 We later made it less strict, because if anything make the dataproxy not initialized, nothing is displayed on the app side with no logs, making it hard to debug for the developer. See #2801 However, we still met situations with no rendering, because the dataproxy was not available at all: - Public sharing: cozy/cozy-drive#3439 - Unsupported shared workers: cozy/cozy-web-data-proxy#36 So now, we always render children, and expect the `DataProxyLink` to handle queries made on non-ready DataProxy by queuing them: cozy/cozy-client#1622
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SharedWorker are not available everywhere:
https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker#browser_compatibility
It is typically not available at this moment on android mobile chrome
and opera, causing a blank screen for apps using the DataProxy on those
browsers.
Hence, we fallback on traditional web worker for such situation.
Note we do not store local data in web worker context.