Fix loading worker on browsers without CSP "worker-src" directive #4822
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
Until now it was assumed that loading the image blurrer worker would not fail. However, if the browser does not support the CSP "worker-src" directive (like Safari) trying to load the worker would throw an exception which would interrupt the load of Talk itself. Now the exception is caught and logged instead, and the image blurrer reverts to a synced generation if no worker is available (although that should not happen, as the image blurrer is used only on Chromium and Chromium supports the "worker-src" directive). Note that Firefox does not throw an exception when loading a worker if not allowed by the CSP. Moreover, as the worker object is created, it does not seem to be possible to know if the worker is actually not available. This is not a problem, though; the image blurrer is not used on Firefox, and even if it was Firefox supports the "worker-src" directive. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
danxuliu
added
2. developing
bug
regression
feature: frontend 🖌️
The image blurrer worker now is loaded only when it is actually needed, so this should prevent the worker to be loaded on browsers other than Chromium, as well as on Chromium if no call is joined. This indirectly fixes the CSP error shown in Safari when the worker was loaded (as the worker is no longer loaded now in Safari) due to Safari not supporting the "worker-src" directive but requiring "child-src" to be used instead. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
danxuliu
force-pushed
the
fix-loading-worker-on-browsers-without-csp-worker-src-directive
branch
from
bcb6151 to
8a6e439
Compare
Member
Author
|
/backport to stable20.1 |
Member
Author
|
/backport to stable20 |
nickvergessen
approved these changes
Jan 7, 2021
nickvergessen
deleted the
fix-loading-worker-on-browsers-without-csp-worker-src-directive
branch
This was referenced Jan 7, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #4813
Follow up to #4678
Safari does not support the CSP "worker-src" directive, so it failed to create the worker, which caused Talk to fail to load. Now the worker will be loaded only when needed (so only in Chromium), and even if the worker fails to load everything will keep going (a synchronous blurrer will be used instead of the asynchronous one from the worker).
Besides that the CSP "child-src" directive was added too as it is supported by Safari and it is used as a fallback when "worker-src" is not available. Given that Safari does not use the worker and that even if the worker fails to load it will not affect Talk load this is not really needed, but it should prevent a "scary" message in the browser logs.Replaced by a lazy loading of the worker, which should cause the worker to not be loaded in Safari.Pending:
I tried, but my virtual machine was not cooperating...Still uncooperative, but with a lot of patience I was able to test it...) - This pull request does not break anything in Edge. There are broken things, but they are not caused by this pull request :-PFuture: