The WebVR origin trial started in Chrome 56. Chrome 58 is the last release it is intended to be available as an Origin Trial. We have now collected various feedback and are sharing it according to the Origin Trials process.
Note we’re publishing feedback before the end of the trial in order to provide time to land code, enable or disable the feature etc in the first release after the trial ends.
Intent to experiment: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zGAzqfi0e00
During the course of this origin trial we determined that the API shape would need to undergo multiple large scale ergonomics changes. Once those changes have been established we intend to run a new experiment with the revised API.
Chrome Status: https://www.chromestatus.com/feature/4532810371039232
As of March 27, 2017, 218 origins have registered for access to the origin trial. Tokens were renewed 80 times for this feature.
For example, https://sketchfab.com/ used WebVR to provide a VR viewer for their entire library of 1 million+ models.
We found usage was split approximately:
Developers loved having access to VR features in the browser, and frequently cited ease of use and content distribution as high points. Ability to convert existing WebGL content into VR and add VR as a progressive enhancement were also mentioned as positives.
The following requests came for improvements to the WebVR feature:
Support for more devices (especially non-Daydream mobile devices such as Cardboard). Cardboard support is already available in M57 with the appropriate service installed, and we will begin prompting users to install the required service in M58.
Better performance and stability
VR-to-VR page navigation
Finalize the spec
More example code and documentation
Better controller APIs
Better integration with Daydream (ability to reopen Chrome from Home after accidentally exiting, etc.)
Ability to avoid the DON flow
Ability to use the Daydream app button in WebVR applications
A couple of other feature requests were made for features related to the API, but not strictly part of WebVR itself:
Support for Origin Trials on HTTP sites
Support for media autoplay (related to default mobile behavior, not WebVR)
Is the WebVR API shape useful and ergonomic?
Many sites have been able to use the features exposed to create a variety of interesting content, so the feature set appears good.
We received a lot of feedback on how to improve API ergonomics and allow it to mesh better with the rest of the web platform from platform leads during the experiment. The API shape is being completely revised as a result.
Developers had issues with how the VR API interacted with media APIs. User gesture requirements made it difficult to begin playing media after the user had completed the transition into VR, which itself requires a user gesture but triggers a separate calibration process which suspends Chrome (pausing any media). When the calibration process returns control to Chrome the user gesture has been lost and the media remains paused, requiring another user action to resume it. (crbug.com/705733)
Are there use cases supported by earlier version of the API that are not supported well now?
No specific feedback was heard on this point.
Do the gamepad API extensions meet developers needs for VR input?
A fair amount of developer feedback centered around difficulty of using the gamepad API for input. A dedicated VR input API is being considered as a result.
First stable release enabled: Chrome 56 Stable, Jan 31, 2017
First stable release with feature shipped/disabled: Chrome 59 Stable, ~Jun 06, 2017
The following metrics come from UMA and are adjusted for UMA opt in rates.
`navigator.getVRDisplays` was called 274,798 times, an average of 2,348 times per day
`VRDisplay.requestPresent` was called 3,122 times, meaning just over 1% of API uses resulted in a click-through to VR presentation mode.
Usage saw approximately a 10X uptick in early February, coinciding with The Keyword blog post