Intent to Ship: WebXR Device API

[Sam Drazin]

Contact emails

baj...@chromium.org, samd...@chromium.org, mlam...@chromium.org, alco...@chromium.org 

Explainer

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

Spec

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

We are shipping VR Capabilities of the WebXR Device API spec.

TAG review: https://github.com/w3ctag/design-reviews/issues/403

All current feedback has been addressed in the spec, as well as in Chromium.

Summary

We are shipping the core WebXR Device API, which is essentially at parity with WebVR (VR capabilities only).  There will be no AR capabilities at this time. We shipped VR capabilities of WebXR as an origin trial in M76-77, extended the experimentation through M78, and collected feedback on updates to the core API, as well as the addition of Gamepad capabilities.  The API we intend to ship will contain the same capabilities as the origin trial.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/XMLgC_SR0dw/discussion

Note: The “Revised WebVR API” (aka WebVR 2.0) referenced in that thread was renamed WebXR Device API several months later.

Link to Origin Trial feedback summary

A summary of origin trial usage and developer feedback can be found here.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, the API and inline sessions (including “viewer” sessions, i.e. those without sensor data) will be available on all platforms with the exception of WebViews (because of UI components). Support for head-mounted displays and thus true VR depends on platform support. Currently, Chrome supports Android and Windows. Poses for some inline sessions also depend on access to sensors, and support is currently limited to Android. 

Demo link

Samples can be found here: https://immersive-web.github.io/webxr-samples/ 

Risks

Interoperability and Compatibility

Describe the degree of interoperability and compatibility risk. For a new feature, the main risk is that it fails to become an interoperable part of the web platform if other browsers do not implement it. For a removal, please review our principles of web compatibility.

Edge: In development (via Chromium)

Firefox: In development

Safari: No signals

Web developers: Positive signals

Ergonomics

The Gamepad API is available for developers who wish to leverage more advanced controller inputs (track pads, triggers, various buttons).  

WebGL is necessary to use with WebXR, as it represents the graphics backend necessary for creating VR experiences.

Activation

A polyfill is available that offers support for Android and iOS, as well as wraps WebVR support for devices that expose the deprecated API (including Oculus Go, Quest, etc).  Three.js also supports WebXR; other popular 3D rendering libraries for the web are planning on following suit.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Web platform tests: https://wpt.fyi/results/webxr?label=master&label=experimental

We have co-developed a WPT API with Mozilla: https://immersive-web.github.io/webxr-test-api/

Entry on the feature dashboard:

https://www.chromestatus.com/feature/5680169905815552

[Yoav Weiss]

On Tue, Oct 1, 2019 at 12:52 AM Sam Drazin <samd...@chromium.org> wrote:

Contact emails

baj...@chromium.org, samd...@chromium.org, mlam...@chromium.org, alco...@chromium.org 

Explainer

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

Spec

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

We are shipping VR Capabilities of the WebXR Device API spec.

TAG review: https://github.com/w3ctag/design-reviews/issues/403

All current feedback has been addressed in the spec, as well as in Chromium.

Summary

We are shipping the core WebXR Device API, which is essentially at parity with WebVR (VR capabilities only).  There will be no AR capabilities at this time. We shipped VR capabilities of WebXR as an origin trial in M76-77, extended the experimentation through M78, and collected feedback on updates to the core API, as well as the addition of Gamepad capabilities.  The API we intend to ship will contain the same capabilities as the origin trial.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/XMLgC_SR0dw/discussion

Note: The “Revised WebVR API” (aka WebVR 2.0) referenced in that thread was renamed WebXR Device API several months later.

Link to Origin Trial feedback summary

A summary of origin trial usage and developer feedback can be found here.

Can you render that document public?

  

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, the API and inline sessions (including “viewer” sessions, i.e. those without sensor data) will be available on all platforms with the exception of WebViews (because of UI components). Support for head-mounted displays and thus true VR depends on platform support. Currently, Chrome supports Android and Windows. Poses for some inline sessions also depend on access to sensors, and support is currently limited to Android. 

Demo link

Samples can be found here: https://immersive-web.github.io/webxr-samples/ 

Risks

Interoperability and Compatibility

Describe the degree of interoperability and compatibility risk. For a new feature, the main risk is that it fails to become an interoperable part of the web platform if other browsers do not implement it. For a removal, please review our principles of web compatibility.

What's your sense regarding the API's stability and likelihood of breaking changes?

Edge: In development (via Chromium)

Firefox: In development

Safari: No signals

Web developers: Positive signals

Ergonomics

The Gamepad API is available for developers who wish to leverage more advanced controller inputs (track pads, triggers, various buttons).  

WebGL is necessary to use with WebXR, as it represents the graphics backend necessary for creating VR experiences.

Activation

A polyfill is available that offers support for Android and iOS, as well as wraps WebVR support for devices that expose the deprecated API (including Oculus Go, Quest, etc).  Three.js also supports WebXR; other popular 3D rendering libraries for the web are planning on following suit.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Web platform tests: https://wpt.fyi/results/webxr?label=master&label=experimental

We have co-developed a WPT API with Mozilla: https://immersive-web.github.io/webxr-test-api/

Entry on the feature dashboard:

https://www.chromestatus.com/feature/5680169905815552

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_pDDmLpduMh-8fBABMC5Qq%3DvenUbekDCFnxNL50eDJKVtEug%40mail.gmail.com.

[Brandon Jones]

On Thu, Oct 3, 2019 at 11:47 AM Yoav Weiss <yo...@yoav.ws> wrote:

Can you render that document public?

  

Sam tells me that the doc that contains origin trial feedback includes specific usage metrics that should not be shared publicly. Google employees having issues accessing the doc internally should let us know.

What's your sense regarding the API's stability and likelihood of breaking changes?

This has been a major focus for us, and we're feeling confident that the API that we intend to ship here will be stable. In fact we "rebooted" the API at one point with the primary purpose of ensuring better forward compatibility. We've made sure to take into account API feedback from developers, various platform ergonomics advisors, and the W3C TAG. We involved most major VR platform owners in the API's creation, validated that it can be implemented against all major native APIs (including OpenXR, which should cover an increasing number of devices and OSes as time goes on) and ensured that in cases where we believe that there's a chance that the native ecosystem may change course we are well positioned to accommodate it in a non-breaking way. Additionally we've done multiple experiments to ensure that the API can be extended to accommodate new hardware functionality as it becomes available/popular, such as environmental tracking with Augmented Reality, and established a spec modules system within our group to allow for more agile development of said features. 

No API can be guaranteed to be fully future proof, of course, but I'm personally quite proud of the work our group has done to ensure the best possible compatibility with such a rapidly evolving area of tech.

--Brandon

[Yoav Weiss]

LGTM1

On Thu, Oct 3, 2019 at 11:20 PM Brandon Jones <baj...@google.com> wrote:

On Thu, Oct 3, 2019 at 11:47 AM Yoav Weiss <yo...@yoav.ws> wrote:

Can you render that document public?

  

Sam tells me that the doc that contains origin trial feedback includes specific usage metrics that should not be shared publicly. Google employees having issues accessing the doc internally should let us know.

Looking at the doc, highlights seems to be that the API was mostly used in Canary, and only few developers answered the developer survey at the end of it. At the same time, most of those that did were supportive of the API shape and its ease of use.

While I'd have loved to see more "real" usage (as would you, I'm sure), I guess that means that no major issues were found with the initial design.

What's your sense regarding the API's stability and likelihood of breaking changes?

This has been a major focus for us, and we're feeling confident that the API that we intend to ship here will be stable. In fact we "rebooted" the API at one point with the primary purpose of ensuring better forward compatibility. We've made sure to take into account API feedback from developers, various platform ergonomics advisors, and the W3C TAG. We involved most major VR platform owners in the API's creation, validated that it can be implemented against all major native APIs (including OpenXR, which should cover an increasing number of devices and OSes as time goes on) and ensured that in cases where we believe that there's a chance that the native ecosystem may change course we are well positioned to accommodate it in a non-breaking way. Additionally we've done multiple experiments to ensure that the API can be extended to accommodate new hardware functionality as it becomes available/popular, such as environmental tracking with Augmented Reality, and established a spec modules system within our group to allow for more agile development of said features. 

No API can be guaranteed to be fully future proof, of course, but I'm personally quite proud of the work our group has done to ensure the best possible compatibility with such a rapidly evolving area of tech.

 

That's good to know, thanks! 

[rhal...@google.com]

Hi,

Has there been a privacy review of this feature in previous steps?

[Daniel Bratell]

Can a censored version of the origin trial feedback be made public if it's just some specifics you need to keep Google internal?

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhiCEkarrT2OitET9XwfG64ovijns3VhbOt9%2BZEYXxWyw%40mail.gmail.com.

[Mounir Lamouri]

Hi,

This API has been reviewed following the usual Chrome launch process which includes privacy and security reviews.

Regarding the Origin Trial feedback, there isn't any outstanding feedback (usual situation). The Origin Trial allowed us to confirm that many websites are interested by the API and are able to use it. The W3C Working Group also has members that are direct consumers of the API. In my experience, OT feedback can be substantial enough to share when a website A/B test a new API but in this case, there is nothing to A/B test with.

-- Mounir

[Chris Wilson]

Also, the Immersive Web Working Group invited the W3C Privacy Interest Group to its meeting over a year ago to discuss, and we incubated the list of concerns and mitigations at https://github.com/immersive-web/privacy-and-security for a long time before incorporating this guidance into the Web XR Device API.  (So in short, yes, there has been a significant amount of privacy review, inside and outside the WG.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH9LPLdyu4Ce49%3DReATebZRNS3Xi%2BX%3DHZJeMk1G8DRLjNg%40mail.gmail.com.

[Philip Jägenstedt]

LGTM2

Looking over https://github.com/immersive-web/webxr/issues/ and close issues it looks like there's been an unusually high level of multi-vendor interest and collaboration on this spec. However, there are a lot of open issues. Before shipping, can someone triage the open issues and make sure that nothing that will likely lead to interoperability issues in the API surface that's shipping remains?

I know that https://github.com/web-platform-tests/wpt/issues/16294 and https://github.com/web-platform-tests/wpt/issues/16455 stand in the way of getting real results of the test suite at https://wpt.fyi/results/webxr?label=experimental&label=master&aligned, but that is now blocked on Ecosystem Infra work, and so it's not reasonable to block this intent on that.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJK2wqWQsx_zu8pGb3KKTxWcJcHFU7ZctA_Xfm3R37KfosqP-Q%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeQ1QamgA2KewGeAE-hg_DFfO1aT2Z_YBfygWVZugtPbA%40mail.gmail.com.

[Pranjal Jumde]

adding public-...@w3.org to the thread for visibility.

Regards,

Pranjal

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJK2wqWQsx_zu8pGb3KKTxWcJcHFU7ZctA_Xfm3R37KfosqP-Q%40mail.gmail.com.