Document `allowvr` attribute for iframes about webxr HOT 22 CLOSED

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.

from webxr.

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!

from webxr.

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.

from webxr.

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.)

from webxr.

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

from webxr.

@cvan, see #86 (comment) and subsuquent comments.

@toji, should we reopen this to remove the existing documentation of allowvr? See also the last paragraph of #86 (comment).

from webxr.

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.

from webxr.

@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?

from webxr.

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

from webxr.

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

from webxr.

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.

from webxr.

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

from webxr.

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

from webxr.

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.

from webxr.

from webxr.

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.

from webxr.

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.

from webxr.

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).

from webxr.

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).

from webxr.

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

from webxr.

Does anyone have an experience with AR inside <iframe> on iOS?
I am using XRViewer by Mozilla, <iframe> has the following attributes: allowvr="yes" allow="xr-spatial-tracking;fullscreen;camera"
The connection is HTTPS.

The result: 'xr' not in navigator.
After I explicitly instantiate WebXRPolyfill, xr becomes available, however I still fail to request 'immersive-ar'

Is it possible at all to run AR inside <iframe> on iOS?

from webxr.

It won't work in the WebXR Viewer; because of Apple's restrictions, the injected webxr javascript plugin would have to recognize the iFrame and forward all the events too/from the iframe. It would be useful, yes, and was on "the todo list" ... but then Mozilla laid us all off, so I don't think that work is supported anymore.

from webxr.