"Unable to read VR Path Registry ..." warning at startup

RESOLVED FIXED in Firefox 62

Status

()

P4
normal
RESOLVED FIXED
2 years ago
6 months ago

People

(Reporter: ray_engelking, Assigned: kip)

Tracking

(Blocks: 1 bug, {reproducible})

unspecified
mozilla62
reproducible
Points:
---

Firefox Tracking Flags

(firefox62 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Getting 2 new errors with the latest Firefox update 53, and on 54;
Unable to read VR Path Registry from C:\Users\rengelking\AppData\Local\openvr\openvrpaths.vrpath
JavaScript error: chrome://pin4ever/content/pin4ever.js, line 421: TypeError: Components.classes['@mozilla.org/satchel/form-history;1'] is undefined
The second error appears to be from an extension, you should contact the extnesion author directly about that.
Re-labeling and re-classifying this for the first message (which I believe is a warning and not an error, but it is noisy...)

For the WebVR folks, I see that same message even during xpcshell tests that don't do anything related to WebVR...
Component: WebExtensions: Untriaged → WebVR
Product: Toolkit → Core
Summary: Missing functionality: <add summary here> → "Unable to read VR Path Registry ..." warning at startup

Updated

2 years ago
Severity: blocker → normal
(Reporter)

Comment 2

2 years ago
(In reply to Andrew Swan [:aswan] from comment #1)
> The second error appears to be from an extension, you should contact the
> extnesion author directly about that.
> Re-labeling and re-classifying this for the first message (which I believe
> is a warning and not an error, but it is noisy...)
> 
> For the WebVR folks, I see that same message even during xpcshell tests that
> don't do anything related to WebVR...

Thank you; I guess the form-history has been deprecated for 3 to 4 years, and it was just removed. The replacement is FormHistory.jsm, although just learned that all "Legacy" extensions are being replaced with Chrome-like WebExtensions; if I wanted to write extensions like Chrome, I would just use Chrome, and not Firefox.. not sure about the rational behind eliminating all XUL type extensions, but there will be even less reason to use Firefox, when version 57 goes live on November 14th.
(Assignee)

Comment 3

a year ago
The real issue seems to be that WebVR is probing for the OpenVR runtime before hitting WebVR content.

Can we narrow this down to a particular test that is triggering the message from WebVR, or does it happen on all of the xpcshell tests?
Flags: needinfo?(aswan)
(In reply to :kip (Kearwood Gilbert) from comment #3)
> Can we narrow this down to a particular test that is triggering the message
> from WebVR, or does it happen on all of the xpcshell tests?

Dunno, I don't see it in recent test output, but I remember it being quite frequent.  Perhaps its been fixed in the ~3 months since comment 1?
Flags: needinfo?(aswan)
(Assignee)

Updated

a year ago
status-firefox57: --- → affected
Priority: -- → P4

Updated

a year ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

a year ago
Started nightly firefox using "firefox --console" and got:
"Unable to read VR Path Registry from C:\Users\Henrik Gemal\AppData\Local\openvr\openvrpaths.vrpath"
This happens on every startup on OS X and is quite annoying for debugging since it happens later on too (maybe for each new process startup?):

$ /Applications/FirefoxNightly.app/Contents/MacOS/firefox --profile /tmp/vrspam
Unable to read VR Path Registry from /Users/matthew/Library/Application Support/OpenVR/.openvr/openvrpaths.vrpath
Unable to read VR Path Registry from /Users/matthew/Library/Application Support/OpenVR/.openvr/openvrpaths.vrpath

The general policy is that console logging shouldn't be output in official builds either and this happens on a stock Nightly.
Has STR: --- → yes
Keywords: reproducible
I would say more important than the console noise is the fact that this work is happening at startup at all.  Lots of people have worked very hard recently to remove unnecessary work from startup.  However fast reading a vr path registry is, these sorts of things all add up.
(Assignee)

Comment 8

a year ago
I have reproduced it in the current nightly, thanks!  We should indeed not be firing up OpenVR until visiting a WebVR site.

Stay tuned for a patch.
Assignee: nobody → kgilbert
Duplicate of this bug: 1422787
If this is causing main thread I/O, it's much more severe than just the noise caused by the warning. kip, are you still intending to produce a patch soon? :-)
Flags: needinfo?(kgilbert)
(Assignee)

Comment 11

10 months ago
(In reply to Florian Quèze [:florian] from comment #10)
> If this is causing main thread I/O, it's much more severe than just the
> noise caused by the warning. kip, are you still intending to produce a patch
> soon? :-)
I've confirmed that after the tty spam, there is no more I/O on the main thread, but this shouldn't be initializing for that thread -- it should only be running in the GPU process.

I suspect the regression is that VRManager::ManagerInit() is being called twice:

- In GPUParent::RecvInit
- In gfxPlatform::gfxPlatform()

It should be only called once, with the location dependent on if e10s is enabled or not.

If we only support WebVR with e10s enabled, we may be able to simply delete one of these calls.  We need to be careful to test all the platforms [eg for Android/GeckoView] after removing it, or add conditions if needed.

This may be to late to fix for FF60, but can I land the fix shortly after.
Flags: needinfo?(kgilbert)
Blocks: 1414495
In bug 1414495 we are seeing intermittent browser startup hangs during Windows tests. At least some of those appear to be hung on the VRLOG call producing the warning of this bug: see https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c66 and https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c68.

:kip -- Do you expect to resolve this bug soon?
Flags: needinfo?(kgilbert)
(Assignee)

Comment 13

9 months ago
(In reply to Geoff Brown [:gbrown] from comment #12)
> In bug 1414495 we are seeing intermittent browser startup hangs during
> Windows tests. At least some of those appear to be hung on the VRLOG call
> producing the warning of this bug: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c66 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c68.
> 
> :kip -- Do you expect to resolve this bug soon?

I will try some fixes later this week.  There is a chance that fixing the redundant initialization in multiple processes may also solve some other issues I've seen reported.
Flags: needinfo?(kgilbert)
Sorry to pester you :kip, but do you have an update?
Flags: needinfo?(kgilbert)
Comment hidden (Intermittent Failures Robot)
Comment hidden (Intermittent Failures Robot)
Comment hidden (mozreview-request)
Comment hidden (Intermittent Failures Robot)
It looks like that the attached patch broke all builds and nearly all test jobs. A common crash signature is:

> [@ mozilla::gfx::VRManagerParent::RegisterVRManagerInVRListenerThread(mozilla::gfx::VRManagerParent*)]
(Assignee)

Comment 20

7 months ago
(In reply to Henrik Skupin (:whimboo) from comment #19)
> It looks like that the attached patch broke all builds and nearly all test
> jobs. A common crash signature is:
> 
> > [@ mozilla::gfx::VRManagerParent::RegisterVRManagerInVRListenerThread(mozilla::gfx::VRManagerParent*)]

Indeed.  It appears that there are some accesses to the redundantly initialized VRManager.  I'll track these down and update the patch.
Flags: needinfo?(kgilbert)
(Assignee)

Comment 21

7 months ago
After some deeper inspection, it appears that the redundantly initialized VRManager is not connecting to any VR API's once started.  It early-exits during vsync refreshes and is only checking for presence of the OpenVR runtime files at startup.

I'll clean up the redundantly initialized VR Manager, but to fix this particular TTY spam bug, I can defer the checking for the OpenVR runtime files until actually hitting WebVR content.

Updated patch incoming...
(Assignee)

Comment 22

7 months ago
Cleanup of the additional VRManager will be done as part of Bug 1362578 (Move VRManager to its own process)
Comment hidden (mozreview-request)
(Assignee)

Updated

7 months ago
Attachment #8973073 - Flags: review?(rbarker)

Comment 24

7 months ago
mozreview-review
Comment on attachment 8973073 [details]
Bug 1373279 - Avoid checking for OpenVR runtime until hitting WebVR content

https://reviewboard.mozilla.org/r/241610/#review248984
Attachment #8973073 - Flags: review?(rbarker) → review+

Comment 25

7 months ago
Pushed by kgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0f11165c90a1
Avoid checking for OpenVR runtime until hitting WebVR content r=rbarker

Comment 26

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/0f11165c90a1
Status: NEW → RESOLVED
Last Resolved: 7 months ago
status-firefox62: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
status-firefox57: affected → ---
You need to log in before you can comment on or make changes to this bug.