-
Notifications
You must be signed in to change notification settings - Fork 86
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
Should not polyfill in non-secure contexts #111
Comments
Some thoughts:
Two ways those could both be achieved:
I think logging a warning to the console about the discrepency is the best way to go at the moment |
WebVR does work on Oculus Quest on insecure context, but it was confusing when an experience that worked on HTTP, didn't work on HTTPS. |
Speaking as someone who was just bitten by this, I would like something to be surfaced. I use ngrok for testing, and Oculus browser defaults to Issue: the polyfill doesn't necessarily know if WebXR is available IF you were using a secure context. BUT, if could at least print something like "emulating webxr using webvr. This is an insecure http connection, if you browser supports webxr it won't be available over an insecure context, consider trying https." I would have noticed if there was anything reported to the console. |
From the WebXR spec:
The
[SecureContext]
bit there says thatnavigator.xr
should only be available on secure pages (basically either https or localhost - more details here). Native implementations like Chrome's will honor this, returningundefined
fornavigator.xr
, which currently causes the full polyfill to be injected on non-secure pages.In my opinion the polyfill should not inject itself in this case, both to comply with the spirit of the spec and to help developers avoid confusion where their non-secure pages developed with the polyfill "work" but break in the future. Open to discussion of course.
The text was updated successfully, but these errors were encountered: