Intent to implement and ship: WebXR Device API in Firefox Nightly

[Kip Gilbert]

Summary:

The successor to WebVR 1.1, the WebXR Device API 1.0, is nearing finalization. The WebXR Device API follows modern Web API patterns, is extensible additively for augmented reality, enables use within Web Workers, and solves many security problems for the VR and AR enabled web. The spec has been developed jointly by implementers from all major browser vendors, within the W3C Immersive Web Community Group. A full W3C Working Group is now being formed, with a charter and assigned chairs.

As of 2019-10-01 I intend to turn the WebXR Device API 1.0 on by default in Nightly for on all platforms that already support WebVR (Windows, Linux, macOS, and Firefox Reality / GeckoView). Chrome 67 Beta has shipped WebXR as an Origin Trial.

Bug to implement:
Bug 1419190 - [meta] Implement WebXR 1.0
https://bugzilla.mozilla.org/show_bug.cgi?id=1419190 <https://bugzilla.mozilla.org/show_bug.cgi?id=1419190>

Bug to turn on by default in Nightly:
Bug 1479617 - Enable WebXR 1.0 by default in Nightly
https://bugzilla.mozilla.org/show_bug.cgi?id=1479617 <https://bugzilla.mozilla.org/show_bug.cgi?id=1479617>

Link to standard:

The api is documented on the immersive-web GitHub page:

https://immersive-web.github.io/webxr/ <https://immersive-web.github.io/webxr/>

The “API Explainer” is a good place to start for newcomers to the WebXR Device API:

https://github.com/immersive-web/webxr/blob/master/explainer.md <https://github.com/immersive-web/webxr/blob/master/explainer.md>

Platform coverage:

WebXR will be supported everywhere that WebVR is currently. This includes Windows, Linux, macOS, and Android/GeckoView (Firefox Reality).

Estimated or target release:

The implementation is expected to be completed for Firefox 73, but would be enabled as early as Firefox 71 if implementation goes quickly.

Preference behind which this will be implemented:

The dom.xr.enabled pref will enable the WebXR Device API. Initially, this will be flipped for Nightly only. Once final TAG review feedback has been completed, any late breaking changes will be implemented before enabling in Release. A separate "intent to ship in release” will be sent to announce this.

Flipping the dom.xr.enabled pref will not disable the existing WebVR api. We wish to keep WebVR enabled for a grace period until most popular engines and sites (eg, threejs and aframe) have migrated to WebXR. An “intent to unship WebVR” will be sent with details of this deprecation once WebXR is in release.

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>

Do other browser engines implement this?
Chrome has implemented this with an origin trial expected to start in Chrome 67, for both desktop and Android.
https://www.chromestatus.com/feature/5680169905815552 <https://www.chromestatus.com/feature/5680169905815552>

web-platform-tests:
Additional web-platform-tests for WebXR will be added during our implementation and submitted to the repo:
https://github.com/web-platform-tests/wpt/tree/master/webxr <https://github.com/web-platform-tests/wpt/tree/master/webxr>

A meta bug has been created to track the needed tests as they are identified:
Bug 1479626 - [meta] Implement web-platform-tests for WebXR
https://bugzilla.mozilla.org/show_bug.cgi?id=1479626 <https://bugzilla.mozilla.org/show_bug.cgi?id=1479626>

Is this feature restricted to secure contexts?
Yes. All implementers in the W3C CG have agreed to enable only in secure contexts.

How stable is the spec:
Final TAG review and W3C Working Group discussion may result in late breaking changes. These changes are expected to affect the syntax of the API and not the general behaviour. Any changes are expected to be identified before our implementation is ready to ship to release.

[kgil...@mozilla.com]

Correction: "As of 2019-10-01" should be "As of 2018-10-01"...

[kgil...@mozilla.com]

On Monday, July 30, 2018 at 5:22:05 PM UTC-7, kgil...@mozilla.com wrote:
> Correction: "As of 2019-10-01" should be "As of 2018-10-01"...
>

Also.. Should be "The implementation is expected to be completed for Firefox 66, but would be enabled as early as Firefox 65 if implementation goes quickly. "

[Boris Zbarsky]

On 7/30/18 8:03 PM, Kip Gilbert wrote:
> Link to standard:

Kip,

Could you please ensure that all the relevant .webidl files have links
to the relevant bits of the standard at the top of the file (and on the
individual interface definitions if there are multiple interfaces in the
file)? See Navigator.webidl for an example of what I'm talking about.
Right now our WebVR IDLs do not have such links, and that makes working
with those files a lot more difficult and error-prone than it really
should be.

> The api is documented on the immersive-web GitHub page:
>
> https://immersive-web.github.io/webxr/ <https://immersive-web.github.io/webxr/>

Is this meant to replace the existing WebVR APIs or augment them?
Sounds like replace in the long term?

> Final TAG review and W3C Working Group discussion may result in late breaking changes. These changes are expected to affect the syntax of the API and not the general behaviour. Any changes are expected to be identified before our implementation is ready to ship to release.

Sounds great. :)

-Boris

[Eric Shepherd (Sheppy)]

Thank you; that will help the docs team very much as well.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshe...@mozilla.com>

[L. David Baron]

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)

[kgil...@mozilla.com]

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.

[kgil...@mozilla.com]

There has been much work in the W3C Immersive-Web Working Group on WebXR since this original intent-to-implement-and-ship thread was started.

The spec is now stable, without anticipated breaking changes. Other vendors will also be imminently shipping WebXR.

WebXR will now be using feature-policy:

https://www.w3.org/TR/webxr/#feature-policy

Earlier today, Mozilla posted "Intent to prototype: Delegate and restrict permission in third party context":

https://groups.google.com/forum/#!topic/mozilla.dev.platform/BdFOMAuCGW8

WebXR will utilize this system to allow delegation.

The WebXR spec has been split into modules, similar to those used for CSS. We intend to ship the "WebXR Core" and "WebXR Gamepads" modules initially. Other modules in "incubation" are not in scope for this intent-to-implement-and-ship.

And updated target for WebXR is now FF73.