Webxr: Document `allowvr` attribute for iframes

Created on 2 Jun 2016  Â·  22Comments  Â·  Source: immersive-web/webxr

Issue by cvan
_Tuesday Mar 01, 2016 at 21:38 GMT_
_Originally opened as https://github.com/MozVR/webvr-spec/issues/17_


We want to add a new attribute allowvr that can be set on <iframe> (à la allowfullscreen).

This attribute can be set to true if the frame is allowed to access VRDisplay objects. When false, navigator.getVRDisplays() and navigator.activeVRDisplays will resolve and return empty sequences.

Most helpful comment

To enable xr to an iframe the attribute is now xr-spatial-tracking:

<iframe allow="xr-spatial-tracking"></iframe>

This only needs to be done when the embedded page is not from the same domain.

All 22 comments

As per discussions with the rest of the implementors, we shouldn't pursue the allowvr route for the final WebVR spec, as the allowfullscreen style of permission is something that the web is trying to move away from as a platform.

As per discussions with the rest of the implementors, we shouldn't pursue the allowvr route for the final WebVR spec, as the allowfullscreen style of permission is something that the web is trying to move away from as a platform.

I'm cool with this change, and I'm curious: are there other efforts to approach solving this problem? (I'd assume there's something in the WHATWG HTML5 Living Standard docs.)

I found https://html.spec.whatwg.org/multipage/browsers.html#nested-browsing-contexts, which seems relevant.

@cvan, see https://github.com/w3c/webvr/issues/86#issuecomment-261835614 and subsuquent comments.

@toji, should we reopen this to _remove_ the existing documentation of allowvr? See also the last paragraph of https://github.com/w3c/webvr/issues/86#issuecomment-262664888.

I proposed that on our last call, but Microsoft says they intend to implement it temporarily for WebVR 1.1, so we'll want to leave it in that version of the spec. It can be removed from ToT.

@toji, thanks for the update. I worry about leaving such text without a warning to implementers and authors that they (probably) shouldn't implement it or use it, respectively. Does it make sense to add an issue box (or note) for such known or potential breaking changes?

After deliberating this issue internally, we’ve decided to not implement allowvr in Microsoft Edge; we support removing it from WebVR 1.1.

Thanks for the update Frank! I'll put up a pull request for that today.

What's the suggested alternative to <iframe allowvr>? The WHATWG HTML5 Living Standard seems to (still?) allow the allowfullscreen, allowpaymentrequest, and allowusermedia attributes on <iframe>s.

Is <iframe sandbox="…"> (see this table) the preferred way of sandboxing <iframe>s going forward?

@annevk, do you know of any open GitHub issues or mailing-list discussions you could point us to about rumours of potentially deprecating <iframe allowfullscreen>, etc. in favour of a better solution? Thanks!

I don't think is anything is being deprecated and things that need to ship soon get an allow* attribute as allowpaymentrequest just got. However, https://github.com/WICG/feature-policy is a likely better solution going forward, but it's not ready yet.

So was this killed or not? If not, why are there still tests in WPT using allowvr?

I'm also curious. iframes will be needed for a lot of CMS use cases, like Wordpress and Ghost.

To be fair, they aren't _needed_ for Wordpress and Ghost, but will certainly make it simpler for plugin developers for those platforms. Having just hacked up some Ghost templating, it's trivial to add content to a page without iFrames.

Are you sure? Doesn’t Wordpress use iframe for YouTube videos? I’d assume we would need the same.

On Mar 4, 2019, at 9:55 AM, Blair MacIntyre notifications@github.com wrote:

To be fair, they aren't needed for Wordpress and Ghost, but will certainly make it simpler for plugin developers for those platforms. Having just hacked up some Ghost templating, it's trivial to add content to a page without iFrames.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/immersive-web/webxr/issues/25#issuecomment-469350854, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ5yvmoHcDo-eHKtXHLXTMOxSSsDoCsks5vTV4tgaJpZM4IsD7d.

Some _sites_ (youtube, twitter, etc) are set up to require the use of iframes to allow their content to be embedded in other pages. That's not a Wordpress/Ghost limitation.

Embedding VR content in iframes will also be useful for third-party content hosting sites/games platforms like Construct Arcade will eventually be, where the content needs to be isolated from the rest of the page.

As far as I can tell, allowvr is removed from the spec and iframes have the permssion to run VR content always.

Good point, @Squareys ... I've run into things like this with games and plugins in the past (e.g., I ran a game design class where the students posted their games to a blog page, and Unity freaked out when multiple games were visible at once).

FWIW, I didn't mean to argue against this feature, I mostly meant that we need solid reasons for it. If I re-interpret @joshmarinacci's point to be that Wordpress and Ghost may want to show multiple WebXR content elements at once (because multiple posts are shown at once), then I'm 100% in agreement that this is a critical need. (and, of course, that's probably part of what Josh meant).

Yeah, I wasn't very clear. Iframes are a great way to encapsulate content and safely share something from one site on another. I expect it will be a very popular way to distribute WebXR content, just as it is common for videos (youtube) and code (codepen).

To enable xr to an iframe the attribute is now xr-spatial-tracking:

<iframe allow="xr-spatial-tracking"></iframe>

This only needs to be done when the embedded page is not from the same domain.

Thanks @mrdoob , added that property to the iframe tag and it now works well in oculus quest. But not in iOS somehow.

Does anyone have an experience with AR inside