-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determines whether PUBLIC_URL is same-origin before registering SW. #2432
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions. |
It should always be provided; it just may be blank. This is changing in the near future. Either way; this code should work. |
I'm guessing we will need to add Would it be better to use Node's url.parse(url.resolve(window.location, process.env.PUBLIC_URL))
|
All browsers that support service workers support the URL object, and the code that uses the URL object is conditionally executed inside of a block that first checks for SW support. So it seemed safe to use the native If we shouldn't use |
Oops, I overlooked this. Great! |
Thanks! |
R: @Timer @gaearon
FYI: @addyosmani
This is a bit more explicit than trying to use a regular expression. It uses the
URL
object inside of a block that first checks to see ifnavigator.serviceWorker
is defined;URL
should always exist in browsers that support service workers.From testing locally, I saw scenarios in which
process.env.PUBLIC_URL
wasn't set at all (which contradicts what @Timer suggested in the issue).The code in this PR should behave properly regardless of whether it's unset, whether it's set to a local path, or whether it's set to a full URL.
Fixes #2374