Hi David, These are all great points, thanks for reviewing this.
The intent is to not allow WebXR in any iframe (not just sandboxed ones), until the discussions have settled. I appreciate the feedback on the feature policy approach and how the origin would be presented to the user. Much of the recent activity in the community group is related to session creation, ensuring that each UA can prompt the user in the most appropriate way without affecting content. The prompts may vary, for example, if using a headset connected to a traditional PC versus an all-in-one VR computer such as the "Oculus Go". Some vendors may opt to present more granular information about a WebXR presentation request (eg, notify user that site is requesting specific geometry for world understanding and to present to their full FOV) while others may opt to present a catch-all (eg, the site is requesting access to all your sensors and camera feed). I'll raise the concern about about delegation and what domain to associate with in the community group. This is a very good point. The intent is to follow a fail-safe approach, that will not result in sites working now that would break later. If the specifics on iframe WebXR usage are settled before implementation is complete, I hope to also enable iframe WebXR usage accordingly. On Tuesday, August 7, 2018 at 2:07:06 PM UTC-7, David Baron wrote: > On Monday 2018-07-30 17:03 -0700, Kip Gilbert wrote: > > Is this feature enabled by default in sandboxed iframes? > > WebXR will not be enabled by default in sandboxed iframes. This will > > likely be enabled later, by use of Feature Policy: > > https://github.com/immersive-web/webxr/issues/86 > > <https://github.com/immersive-web/webxr/issues/86> > > I'm curious why this is specific to sandboxed iframes, rather than, > say, any cross-origin iframes (and perhaps also same-origin > sandboxed ones). > > That said, some of this concern comes from not being sure what it > looks like to a user if a page wants to use XR. Is there some sort > of permission prompt or request that the user sees first? > > If there is... what domain is it associated with? > > One of the goals of feature policy is to allow permission requests > be *associated* only with the toplevel page. This is useful since > permission requests coming from subframes aren't particularly > meaningful and are also confusing -- they don't correspond to the > URL bar, it's not clear what persisting them would mean, etc. > > A page would be able to use feature policy to delegate their ability > to use/request capabilities to a cross-origin frame. Without that > delegation a cross-origin subframe would not have access to the > capability; with the delegation requests from the cross-origin frame > would appear as though they come from the toplevel document (and if > remembered, would be remembered as such). > > *If* something like that is the model here, then maybe a > cross-origin iframes restriction rather than a sandbox iframes > restriction makes more sense. > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
