Should not polyfill in non-secure contexts

[lojjic]

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]

Some thoughts:

• :+1: 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]

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]

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.