The "Under Neon Lights" site works when opening the embedded iframe's URL directly: https://player.with.in/embed/?id=541&resolution=1280&forced=false&autoplay=true&t=0&internal=true

The iframe has a different origin than the top-level document. Starting in M62, this must be enabled via Feature Policy. For example, adding the attribute allow="vr" to childe iframes.

I filed  issue 764447  to replace the exception message with one that is more helpful for this case.

For debugging on our end.., is Canary running 62 on Chrome for Android?

Dev and Canary are on M63 now, but the behavior should be the same. Beta is on M62. You can check the (rough) current status at https://omahaproxy.appspot.com/.

Awesome, thanks!

It looks like on non Chrome 62+ web browsers allow="vr" throws an error. "Error while parsing the 'allow' attribute: 'vr' is an invalid feature name." How do we, as developers, handle both cases?

+iclelland

Is that Chrome <=61 or other browsers? If others, which ones?

Looks like Chrome <= 61 and Safari (I'm on 11). Checked on FF and Microsoft Edge as well.

Sorry to be more explicit. Errors were thrown for Chrome <= 61 and Safari. The latest FF and Edge stable didn't throw any errors.

That makes sense; FF and edge won't recognize the allow attribute at all. Chrome should support it without any issues (and the "Error while parsing" should really just be a console warning, rather than an actual error).

Chrome 62+ should support the 'vr' feature, and use it to allow 3rd-party origins to use WebVR in iframes.
Chrome <= 61 didn't use feature policy at all, and I don't think they supported 3rd-party origins in frames. (Or possibly didn't support WebVR in frames at all) +bshe who should know for sure.

Thanks, iclelland.

Prior to M62, WebVR could be use in cross-origin iframes. For the new WebVR Origin Trial started in M62, such use requires Feature Policy. So as long as this is just a console warning, M61 should work just fine.

jono, is this causing problems in Chrome 61 or were you just concerned about the warning?

Cool, thanks for the clarification. When I apply the attribute in JavaScript like

var iframe = document.createElement("div");
iframe.setAttribute("allow", "vr");

is a breaking error in Chrome 61 and below. It's not a dealbreaker but we'll just have to do some additional handling so it doesn't break the thread.

Do you get an error when you run those two lines? I just ran them in Chrome 60 and 61 without any issues.

Yes, this is the error I get: "Error while parsing the 'allow' attribute: 'vr' is an invalid feature name."

The code in #15 is incorrect. It should be s/div/iframe/.

The following will show a successful "vr" call in M62+ and "foo" always reporting an invalid name. However, these are just console messages, and the script continues to execute.

var iframe = document.createElement("iframe");
iframe.setAttribute("allow", "vr");
iframe.setAttribute("allow", "foo");
console.log("finished");

The console error message in #17 was replaced with a different console warning message ("Unrecognized feature: 'foo'.") in https://chromium-review.googlesource.com/c/chromium/src/+/620948. Neither was an exception, so they can be safely ignored.

Ah, sorry about that. I meant to put document.createElement('iframe'). Div is just second nature for me.., heh.

The blocking error I actually get is from jQuery because we're setting the attribute through that framework. I'll set it directly on the DOM element via setAttribute.

Thanks!

This patch is staged on the Within website and should hit later today. I'll report back when it's propagated.

The fix is live, and VR works again in Canary. Thank you, jono@.

Out of curiosity, how were you setting the attribute before that caused a blocking error? We'd like to understand any potential issues with feature policy.

verified this works with 63.0.3233.0

Regarding Comment 21: the blocking error was coming from jQuery because I
was setting the attribute through a selector. e.g:
$('iframe').attr('allow', 'vr'); I got around that by not relying on jQuery
and used setAttribute directly.

Thank you guys for the awesome WebVR API!

jono -- If you can come up with a minimal test case where the allow attribute is broken with jQuery, could you file another bug for it? I'd love to look into that, and see if there's still something strange going on there.

Thanks!