Skip to content
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

Open
lojjic opened this issue Nov 8, 2019 · 3 comments
Open

Should not polyfill in non-secure contexts #111

lojjic opened this issue Nov 8, 2019 · 3 comments

Comments

@lojjic
Copy link
Contributor

lojjic commented Nov 8, 2019

From the WebXR spec:

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute XR xr;
};

The [SecureContext] bit there says that navigator.xr should only be available on secure pages (basically either https or localhost - more details here). Native implementations like Chrome's will honor this, returning undefined for navigator.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.

@jsantell
Copy link
Contributor

jsantell commented Nov 8, 2019

Some thoughts:

  • 👍 for attempting to match a real implementation so there's no shock when trying on a supported browser.
  • It's valuable to test the polyfill locally -- browsers have secure context escape hatches via flags or blessed URLs (localhost, 127.0.0.1, etc.). It should continue to work locally without running an HTTPS server.

Two ways those could both be achieved:

  • console.error a message when the polyfill executes in an insecure context. This can be approximated by checking the protocol, with the edge cases being perhaps a browser deems an SSL "insecure", or breaking an iframe policy. Still testable locally, message in the console of the discrepency, similar to API monkeypatching (ex: "fooBar() is deprecated; please use requestFooBar()").
  • Require a flag to the polyfill that allows execution even in insecure, local contexts. Would be a pain to flip this on and off when going through a suite of examples like webxr-samples, and still may have this enabled when in non-development.

I think logging a warning to the console about the discrepency is the best way to go at the moment

@De-Panther
Copy link
Contributor

De-Panther commented Apr 11, 2020

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.
So adding a warning that says that the experience is using Polyfill and WebXR isn't working on insecure contexts could help.

@blairmacintyre
Copy link
Contributor

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 http instead of https if you type in a domain, both of which work with ngrok. I was testing a WebXR app and it was not working, behaving weird, etc., and finally someone suggested this might be the reason (webxr not being exposed because of http, polyfill faking it with webvr).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants