WebXR not working on Chrome Desktop Windows

[dmarcos]

Chrome has switched from vendor specific APIs to OpenXR. Oculus and Valve have shipped experimental runtimes on their respective beta channels. It requires users to opt in. Once the OpenXR implementations ship on the release channels WebXR will work automatically. No changes required on the A-Frame side. Keeping this open as a reference.

[dmarcos]

@JoeLudwig Is there any ETA for Valve to ship an OpenXR runtime on release channel? Thank you!

[JoeLudwig]

OpenXR support in SteamVR is in the release channel now. It's not yet conformant, however. The main limitation is that it only supports one projection layer. Not sure if that matters for WebXR.

We don't have an ETA for when we'll finish up support for multiple projection layers and finalize conformance.

[dmarcos]

@JoeLudwig Thanks Joe. Much appreciated

Just gave it a try with the WebXR sample. Something is happening but not fully working. I can click on enter VR, see the Chrome loading image in Steam VR and then the display goes black. Content doesn't present in headset and there are no console errors.

I can see navigator.xr.requestSession('immersive-vr') succeeding and a proper WebGL layer initialized

I'm on SteamVR 1.14.16 and Chrome 86 using an Oculus Rift over Steam VR. Native VR content works as expected. Below a screenshot of the setup:

@toji Any step I might be missing or configuration needed in chrome://flags?

[klausw]

Diego, when installing/upgrading SteamVR, did you get a "SteamVR needs to set itself up for App Containers" prompt, and did you grant that permission? I don't know offhand if there's a way to check retroactively if that's set up correctly.

"The requested session requires user activation" may be a red herring, did you set a breakpoint at the requestSession call? The user activation state the app gets from clicking the "Enter VR" button expires after a few seconds (5s I think), and if it's stopped at the breakpoint longer than that, requestSession fails with that error.

There should not be any flags needed for Chrome when using OpenXR with App Container support, but would you be willing to try a newer channel such as Chrome Dev or Canary to see if that behaves differently?

I'll give it a shot on my Windows machine also to compare, it had worked last time I tried but I don't remember which Chrome version that was.

[dmarcos]

Sorry, the The requested session requires user activation error was from a previous test. I hadn't clear the console. Updated the image above to reflect the real state. I see a pose coming in too. Still nothing in headset.

I indeed saw the SteamVR needs to set itself up for App Containers prompt. The test above is done after accepting

[JoeLudwig]

What does this show in your settings?

[dmarcos]

I had everything Off and Current OpenXR Runtime set to Oculus. I switched to SteamVR and get similar results. The browser enters VR mode but doesn't present in headset. I get now Chrome next up prompt in the SteamVR space instead of the Oculus runtime equivalent.

Below my settings for reference

[klausw]

It's also not working for me. requestSession succeeds, but the session rAF callbacks don't get run, and the headset just shows the home menu.

I tried:

88.0.4300.0 (Official Build) canary (64-bit) (cohort: Clang-64) 87.0.4280.27 (Official Build) beta (64-bit) (cohort: Beta) 86.0.4240.75 (Official Build) (64-bit) (cohort: Stable)

This was generally with no flags: "[...]\Google\Chrome SxS\Application\chrome.exe" --flag-switches-begin --flag-switches-end

I also tried with --disable-features=XRSandbox which didn't seem to make a difference.

This is using SteamVR beta 1.15.4 on Windows 10 OS Version 2004 (Build 19041.572).

[dmarcos]

Thanks @klausw @JoeLudwig for investigating.

@Artyom17 Do you know if there's any ETA for Oculus to ship the OpenXR runtime on the release channel? Thank you!

[klausw]

In case it helps, here are messages from SteamVR Developer / Web Console when I try to start a session in Chrome Beta:

vrserverThu Oct 22 2020 15:08:48.314 - lighthouse: LHR-033AC4CE H: SOB: drop S-1 seeing S-11 (6E2E9096)
vrserverThu Oct 22 2020 15:08:50.195 - StartSceneApplicationTransitionFromProcess( 16280, C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe, system.generated.chrome.exe)
vrserverThu Oct 22 2020 15:08:50.195 - AppInfoManager.ProcessConnected BEGIN 16280 C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe 10 system.generated.chrome.exe
vrserverThu Oct 22 2020 15:08:50.200 - SetApplicationPid appkey=system.generated.chrome.exe pid=16280, external transition
vrserverThu Oct 22 2020 15:08:50.200 - SetApplicationPid: Setting app system.generated.chrome.exe PID to 16280
vrserverThu Oct 22 2020 15:08:50.200 - AppInfoManager.ProcessConnected END
vrserverThu Oct 22 2020 15:08:50.200 - Processing message VRMsg_ChangeAppType from chrome (16280) took 0.00509 seconds
vrserverThu Oct 22 2020 15:08:50.203 - Unable to find input profile for holographic_controller in SetXrInputConfig
vrwebhelper_controllerbindingThu Oct 22 2020 15:08:50.257 - CEF Local Resource Load Error: http://localhost:27062/app/image?app_key=system.generated.chrome.exe&version=1.15.4 -> 404 (Not Found)
vrwebhelper_systemuiThu Oct 22 2020 15:08:52.238 - CEF Local Resource Load Error: http://localhost:27062/dashboard/css/images/appimage_default.png -> 404 (Not Found)

[klausw]

Forgot to add earlier, I was testing with a Valve Index headset using the SteamVR OpenXR runtime.

Interestingly, it's now working for me on Chrome stable (86) and Canary (88). (I didn't retest 87.), using the default OpenXR runtime with no Chrome flags.

There seems to be an issue related to the SteamVR library menu (I have Steam Home disabled). When I start SteamVR, it displays the Library panel with recent games and system functions at the bottom. While this panel is open, Chrome can start a WebXR session, but it doesn't receive ongoing animation frame callbacks, and output seems inconsistent - sometimes I see a frozen frame behind the SteamVR Library panel, other times not.

If I use the headset's system button to close the SteamVR Library panel, the WebXR page starts showing, and everything seems to be working normally including the expected rAF callbacks.

Exiting the WebXR page through the browser's "Exit VR" button leaves a frozen frame behind.

[JoeLudwig]

Does Chrome destroy the OpenXR instance when the ExitVR button is pressed?

AFAIK Oculus shipped their OpenXR support in July.

[alcooper91]

We shouldn't be destroying it when the ExitVR button is pressed (at least from 86+); I think we did previously, but we hit some issues with SteamVR only allowing one instance to be created (which is allowable by the spec), so now we only destroy it when either the headset is removed or no open pages have queried for XrSupport.

[klausw]

"headset is removed" in this case meaning getting unplugged or similar actions that cause the OpenXrDevice to get destroyed. (I was briefly confused thinking this was referring to the headset's proximity sensor, thanks Alex for clarifying.)

[dmarcos]

Thanks everybody for participating. There's more clarity now.

I tried Chrome 86 (Release) and 88 (Canary) on the WebXRS sample with an Oculus Rift and Oculus runtime Version 21.0.0.473.119 (SteamVR is not running)

navigator.xr.isSessionSupported('immersive-vr') returns false. If the Oculus OpenXR runtime has shipped perhaps is not enabled by default?

[cabanier]

I asked our engineers working on the OpenXR driver for Oculus Rift and they suspect that it is an issue with setting the active openxr runtime. In your registry what is HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenXR\1 set to? It should be C:\Program Files\Oculus\Support\oculus-runtime\oculus_openxr_64.json

[dmarcos]

@cabanier Thanks. It's set to C:\Program Files (x86)\Steam\steamapps\common\SteamVR\steamxr_win64.json I switched to C:\Program Files\Oculus\Support\oculus-runtime\oculus_openxr_64.json and I can enter VR but have the same issue as with the SteamVR OpenXR runtime.

navigator.xr.requestSession('immersive-vr') succeeds with the WebXR sample and Chrome 86/88 but no content presented in headset. Display remains black. If I exit VR mode the Oculus Home renders again.

Can anyone at Oculus reproduce as well or is it just me?

[alcooper91]

I know of one other person that saw a similar issue, where the Oculus headset didn't seem to render. It seemed like a timing issue, as Debug builds worked, but Release builds did not.

[cabanier]

I was told we test with latest Chrome and Chrome Canary.

[dmarcos]

@cabanier Thanks. I tested with those too. Chrome (86) and Canary (88) at the moment.

Are users expected to change the Windows registry to make Chrome and WebXR work? If that's the case, what happens if someone uses both SteamVR and Oculus runtime (because they own games on both or have multiple headsets)? Do the they have to edit the registry depending on the runtime used? Is there any mechanism planned to make it transparent to the user and automatic? Sorry for all the questions. I know you might no have the answers now. Just putting them out there.

[cabanier]

Are users expected to change the Windows registry to make Chrome and WebXR work?

Yes, this is how it's documented on khronos

If that's the case, what happens if someone uses both SteamVR and Oculus runtime (because they own games on both or have multiple headsets)? Do the they have to edit the registry depending on the runtime used?

It seems that these are questions for the Khronos group. Hopefully there will be a UI so users can make a choice.

[JoeLudwig]

Users will change the registry, but probably not with regedit. All three major PC runtimes will set themselves as the current runtime if they start up and nobody else is set. They will also generally select themselves if the user uses a headset that uses that runtime.

In SteamVR's case it will set itself as the current runtime when SteamVR starts with a Lighthouse headset, or there's a button in settings that will do it at any time regardless of headset.

[dmarcos]

@JoeLudwig Thanks Joe. In the case of Oculus it looks like the Oculus runtime starts automatically when launching Steam VR and a Rift connected. What runtime will be selected in that case?

At the moment It's hard to evaluate the different scenarios since WebXR doesn't work on Chrome neither with Oculus nor SteamVR OpenXR runtime (at least on my machine)

@alcooper91 Are you able to get any WebXR content presenting with Chrome with any headset or runtime? Are there any known bugs on blink / chrome we should keep track of?

Hopefully we can get to a point where it's plug and play. User connects headset, visits site, clicks enter VR and everything works without changing settings or knowing about OpenXR / runtimes.

[JoeLudwig]

If the user has an Oculus headset SteamVR won't touch the registry automatically. It will only change the registry when the user clicks the "Set OpenXR to point at SteamVR" button in settings.

[alcooper91]

Yes, I've been able to load WebXR sessions with WMR's OpenXR runtime, I believe Klaus was able to enter with a Valve headset through the SteamVR OpenXR runtime. It sounds like there may be some issue specific to Oculus's implementation/SteamVR talking with Oculus.

The co-worker who reported the Oculus issues is out right now, I'll ask him on Monday if he had filed an issue for the behavior he was seeing (nothing rendering on Oculus), which sounds like the behavior you were seeing. The only other issue I know of affects session termination, especially if that termination was originated by the runtime and not via session.end(). There's two bugs on that right now: https://crbug.com/1139279, https://crbug.com/1065149 (they are likely the same bug).

[dmarcos]

@alcooper91 Thanks for the info.

[De-Panther]

I'm using Chrome 86.0.4240.111 and Oculus 23.0.0.18.517 (Public test channel enabled) and Oculus Link/Quest. No special flags are on, so it uses OpenXR.

WebXR works for me.

My only issues are that squeeze and trigger are not rounded when they should be 0 or 1, and that there's no haptic feedback. (squeeze and trigger rounded issue happens in Firefox, so I guess it's Oculus/OpenXR issue, while haptic feedback works on Firefox, so I guess it's an implementation issue in Chrome)

[alcooper91]

It seems there's likely something machine-specific that causes Oculus over OpenXR to work/not work, as we currently suspect it's some form of timing issue, but it's still good confirmation to hear that it is working for someone :).

squeeze and trigger rounded issue happens in Firefox, so I guess it's Oculus/OpenXR issue

Chrome (and I'm assuming Firefox as well), looks to just plumb the "value" from the runtime without additional rounding, so I think this is correct.

while haptic feedback works on Firefox, so I guess it's an implementation issue in Chrome

That is correct, Chrome hasn't implemented haptic feedback for the WebXr Gamepads.

[dmarcos]

@De-Panther Thanks for investigating. Much appreciated.

Chrome (86 and 88) doesn't work for me either on Oculus Public Test Channel (Version 23.0.0.18.517) and the WebXR Sample. Just the Oculus runtime. No SteamVR running. navigator.xr.isSessionSupported('immersive-vr') returns false

[dmarcos]

Update. I have now access to a Valve Index. I can consistently enter VR with Chrome 86 after setting SteamVR as default OpenXR runtime when Steam suggests at launch.

On the same machine I haven't been able to enter VR with Oculus Rift in any configuration. I tried with:

• SteamVR + Steam OpenXR runtime set as default (same combo that works with Index).
• Oculus OpenXR runtime set as default (via regedit) and 21.0.0.473.119 runtime
• Oculus OpenXR runtime set as default and 23.0.0.43.517 runtime (Beta channel)

Firefox enters VR as expected in all configurations.

[De-Panther]

I think that Firefox still uses WebVR and relay on the polyfill (edit: for WebXR)

[dmarcos]

Firefox is indeed using WebVR (no polyfills) and I don't think it has an OpenXR back-end. It negotiates directly with the vendor SDKs. I added the info for completeness.

[driescroons]

If it helps anyone; I had the same issue in chrome 86 and 87 with WebXR Incubations set to enabled and the Force WebXr Runtime flag set to openXr. I've set both to default on chrome 87 and now my chrome apps are opening within my valve index.

This was after I read the reply of @klausw where he said this:

Interestingly, it's now working for me on Chrome stable (86) and Canary (88). (I didn't retest 87.), using the default OpenXR runtime with no Chrome flags.

[dmarcos]

@driescroons Thanks so much for the info.

[agandia]

I exprienced similar issues. I was trying to run the immersive WebXR example using Oculus Quest 2 with link last Friday (27th Nov) I tried with Chrome 87 and Canary 89, as well as Edge (chromium based) and Mozilla Firefox (latest available download for all).

• set flags
• WebXR Incubations: Enabled
• Force WebXr Runtime: OpenXR

After installing and updating Oculus Desktop app (v 24.0) I realized no registry entry appeared for active runtime, so I had to manually create the following. ActiveRuntime (Expandable String Value) C:\Program Files\Oculus\Support\oculus-runtime\oculus_openxr_64.json

Path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenXR\1

It was not until I installed steamVR and set current OpenXR Runtime to SteamVR that I got it to work (On Canary 89 only)

[dmarcos]

@agandia Thanks for the report. Much appreciated.

@toji Are any of the issues known? Should we report them anywhere? Thanks so much.

[cabanier]

@dmarcos can you try Chrome Canary? I was told we have reason to believe that this is fixed.

[dmarcos]

Thanks. I gave it another try with the Rift and the webxr sample. No luck.

I manually set HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenXR\1 to C:\Program Files\Oculus\Support\oculus-runtime\oculus_openxr_64.json as suggested above

With the Oculus runtime and no Steam / SteamVR running:

• On Chrome release (86) navigator.xr.isSessionSupported('immersive-vr') returns true and navigator.xr.supportsSession('immersive-vr') succeeds. The headset that is displaying the Oculus home goes black when entering VR but no content is presented.

• On Chrome Canary (89) navigator.xr.isSessionSupported('immersive-vr') returns false

I'm on Oculus Runtime Version 23.0.0.43.517

With Steam VR and regedit config above the result is the same as with the Oculus Runtime alone.

Oculus / Steam VR home and any native content run as expected.

Also tried with Oculus Runtime Beta 24.0.0.22.393 and get the same results too.

[iq3connect]

Has anyone tried Vive Cosmos with Chrome 86 or Canary? I can enter VR in the headset, but I cannot get the Cosmos controllers to work. Tried all the WebXR and ThreeJS samples. The OpenXR runtime in the Settings is "SteamVR"

[jure]

One more data point: Chrome 86 Oculus Quest via Link

All settings on default, didn't change anything, I can enter VR, but stuff gets quite strange from there onwards. E.g. in Mozilla's Hello WebXR demo the controllers are upside down. In the link you posted @dmarcos the left and right eyes are switched. Chrome also crashes when exiting VR in multiple (including A-Frame's) demos.

Update:

Chrome 87 seems to improve things, I could start the WebXR session just fine (https://immersive-web.github.io/webxr-samples/immersive-vr-session.html). This also worked: https://rocketvirtual.com/A-Frame_WebXR/Space_Carousel.html Chrome is still prone to crashing when playing with examples.

[De-Panther]

I wonder if all those issues are Chrome issues or Oculus+OpenXR issues. Is there an OpenXR executable for testing?

[cabanier]

I wonder if all those issues are Chrome issues or Oculus+OpenXR issues. Is there an OpenXR executable for testing?

Chrome's multi-process architecture is causing issues with the OpenXR runtime.

[toji]

@cabanier: Do you know if anyone is looking into that? I heard it was a problem before (though apparently not for everyone) but don't know if any progress has been made on it from the Oculus side. If it IS a multi-process issue I doubt there's much on the browser side we can do to mitigate it. That's an important aspect of our security.

[dmarcos]

@jure Thanks for the detailed report.

@toji Thanks for chipping in. Much appreciated

[iq3connect]

All, I can give you a data point. iQ3 implementation works reliably on desktop Chrome 86/87 with Oculus Quest stand alone and link cable. The only remaining issue is the controller pointer is off 90 degs in desktop version (w link cable or Rift S). I understand this is a known issue in Oculus native OpenXR.

[cabanier]

@cabanier: Do you know if anyone is looking into that? I heard it was a problem before (though apparently not for everyone) but don't know if any progress has been made on it from the Oculus side. If it IS a multi-process issue I doubt there's much on the browser side we can do to mitigate it. That's an important aspect of our security.

Yes, I was told it is a problem with the multiprocess architecture. I pinged the engineer again.

[dmarcos]

@cabanier do you know if there has been any changes in the Oculus Runtime in the last few days? It looks WebVR / WebXR is no longer working for all users on desktop: both Chrome and Firefox. Thanks for the info.

[cabanier]

I will check

[cabanier]

@dmarcos is it flaky or completely broken for everyone?

[dmarcos]

@cabanier I asked the users that reported problems to participate here. For me WebXR hasn’t worked at all on desktop since I filed this issue. Tried all the solutions suggested above. I used to test on both Vive / Rift so I imagine that my computer is in weird state related to OpenXR runtimes conflicts. Thanks so much for investigating.