New issue
Advanced search Search tips

Issue 687009 link

Starred by 6 users

Issue metadata

Status: Fixed
Closed: Feb 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Sign in to add a comment

WebVR crashes on vrDisplay.requestPresent()

Reported by, Jan 31 2017

Issue description

Chromium version: 56.0.2902.0  Channel: n/a
OS Version: Window 10 Version 1607 for x64-based systems

Steps to reproduce the problem:
1. Install latest Windows updates on a machine setup for an HTC Vive. 
2. Open a WebVR-enabled site, such as
3. Click “Enter VR”, “View in Vive” or similar to perform vrDisplay.requestPresent()

What is the expected behavior?
Content should get pushed to VR HMD, such as Vive. Instead browser stalls, then crashes. 

What went wrong?
Unclear, but seems to be a conflict with latest Windows updates. 

Did this work before? Yes Same version of Chromium, but prior to OS updates. 

Does this work in other browsers? N/A

Chromium version: 56.0.2902.0  Channel: n/a
OS Version: Windows 10 Version 1607 for x64-based systems
Flash Version:

Comment 1 by, Jan 31 2017

Same issue here:

Windows 10 Home 1607 14393.693 64-bit
Chromium  56.0.2902.0 (64-bit)
Geforce drive 378.49
SteamVR beta 1485823399

In my case I might get a couple of seconds of stereo presentation and then crash. In the SteamVR lobby apperas a floating window with the "busy" indicator.
Same issue, but on Windows 8.1

Windows 8.1 64-bit
Chromium version: 56.0.2902.0
Geforce 376.33

Stopped working after a Windows update, with same behavior as other reporters (Chromium crashes very soon after entering VR)

Note that for me, Firefox performance also degraded - it works only in non-roomscale mode only.
Labels: Needs-Triage-M56

Comment 4 by, Jan 31 2017

I've had the same crashes happening as well. Everything worked fine this morning until 3pm or so. Then after a restart, it would not work at 4:30pm. 

Windows has not updated since 1/26, but SteamVR updated twice today. When I look at the vrserver.txt log after the crash, I see this line over and over, and then steam killing the process:

"Refusing connect from chrome (10144) because app start error VRInitError_Init_Retry"

Chromium version: 56.0.2902.0  Channel: n/a
OS Version: Windows 10 Version 1607

Labels: -Needs-Triage-M56 VR-TD Proj-VR
Status: Available (was: Unconfirmed)
This is an issue with the desktop WebVR builds from, not any official release build.
Status: Started (was: Available)
A new build has been posted to which solves the most immediate crashing issue, but I'm still hearing multiple reports of crashes or issues starting that seem somewhat unrelated. I'll try and follow up with those when I get a chance.
The new version fixed it for me, no issues.
The new version fixed it for cases which did not use gamepads (thank you).  However, if you make a call to navigator.getGamepads() before entering VR it still crashes on entering VR.  This is true even at the Chrome session level as well as within a given page, so 

launch Chrome (VR)
open developer tools and enter navigator.getGamepads()
open a 'harmless' webvr example
enter VR .... crash

There is more on the thread,
but I don't think it it will help more than this most recent minimal and repeatable case.

on the comment: This is an issue with the desktop WebVR builds from, not any official release build.
I didn't think there were any 'official' release builds that include WebVR?  If so, how do we get them?
@bajones, thanks for the fixing! Are you able to share the root cause and the fix before updating the webvr_1 experimental branch?
Status: Fixed (was: Started)
Should be fixed with Gamepads now as well. The branch that the fixed build is built from is: (webvr_1 is quite outdated.)

The root cause was that OpenVR has begun killing off existing "Scene" applications (effectively, those that present frames to the HMD) when a new Scene application is started. Since the browser consists of multiple processes, both of which previously identified as scene applications, beginning presentation would cause the GPU process to become the active scene and the browser process would be killed by Steam.

The solution was to only have the GPU process identify as a scene and the browser process now identifies as an application of type "other".
@bajones. Got it. Thanks for the sharing!
Components: Blink>WebXR

Sign in to add a comment