Closed Bug 1533197 Opened 8 months ago Closed 6 months ago

OpenVR controller can't be enumerated after revisiting a WebVR website


(Core :: WebVR, defect)

66 Branch
Not set



Tracking Status
firefox68 --- fixed


(Reporter: daoshengmu, Assigned: daoshengmu)



(1 file)


  1. Open enter VR. You can see your controllers.
  2. Open an another tab but this one is not a WebVR page, then close the WebVR tab and wait it for a while or checking if the VR process is removed from ProcessExplorer.
  3. Go to enter VR again . You can't see your controllers.

According to the investigation in MozRegression
It causes by But, it was good for while. I am curious if there is some changes since SteamVR 1.2.10. However, if we choose don't reuse the temporary files that we create for actions and manifest. The problem will be solved.

Fortunately, we only enable dom.vr.openvr.action_input by default in Nightly. If we turn it off, we will be good.

This issue is caused by calling VR_Shutdown() after VRSession is closed, then calling VR_Init() to launch a new session but doesn't point back the file patch again.

We were checking if the action manifest has been existing. If this file has been existing, we give an early return. But, we should still set the file to SetActionManifestPath() again after VR_Init().

I think our openvr action-based input has been good enough to turn it on by default in FF release. I will flip dom.vr.openvr.action_input on after Bug 1529105 is resolved.

Assignee: nobody → dmu
Pushed by
Pointing back to the same VR input action manifest file when the file has been existing. r=kip
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.