Closed Bug 1396326 Opened 2 years ago Closed 2 years ago

WebVR pose spins rapidly when tracking is lost

Categories

(Core :: WebVR, defect, P3)

x86_64
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla58
Tracking Status
firefox57 --- verified
firefox58 --- verified

People

(Reporter: ktngo09, Assigned: kip)

Details

Attachments

(1 file, 2 obsolete files)

In all iterations of Firefox with WebVR, when tracking is lost, the 2D screen spins rapidly, reading from the WebVR pose. This can be a headache to look at when developing. Can we detect this and not send pose data?
(In reply to Kevin Ngo from comment #0)
> In all iterations of Firefox with WebVR, when tracking is lost, the 2D
> screen spins rapidly, reading from the WebVR pose. This can be a headache to
> look at when developing. Can we detect this and not send pose data?

Kevin,
Do you have possible STR? I used to have some experience about this, but it happens intermittently.
Priority: -- → P3
I already know how to reproduce it. It can be reproduce by putting Vive headset behind the lighthouse, it will lose tracking and spinning.
Assignee: nobody → dmu
Status: UNCONFIRMED → NEW
Ever confirmed: true
It is easy to be reproduced when visiting https://aframe.io/examples/showcase/helloworld/ and switch to the present mode.
Comment on attachment 8912501 [details]
Bug 1396326 - Restore the previous HMD pose when loosing tracking in OpenVR;

https://reviewboard.mozilla.org/r/183824/#review189380

This patch would fix the issue for a-frame, but also disable the ability for WebVR content to detect when the tracking has gone out of range.

I did some experimentation and found that VRDisplay.getFrameData() isn't properly returning "false" when losing tracking.  I have uploaded a patch to correc this to the bug, which seems to fix the spinning issues in a-frame sites.
Attachment #8912501 - Flags: review?(kgilbert) → review-
This patch fixes the problem by ensuring VRDisplay.getFrameData returns false when no orientation tracking is valid.
Attachment #8912898 - Flags: review?(dmu)
(Updated the patch with some line wrapping)
Attachment #8912898 - Attachment is obsolete: true
Attachment #8912898 - Flags: review?(dmu)
Attachment #8912899 - Flags: review?(dmu)
Attachment #8912501 - Attachment is obsolete: true
Comment on attachment 8912899 [details] [diff] [review]
Bug 1396326 - VRDisplay.getFrameData() now returns false when orientation data is not available

Review of attachment 8912899 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. thanks.
Attachment #8912899 - Flags: review?(dmu) → review+
Assignee: dmu → kgilbert
Comment on attachment 8912899 [details] [diff] [review]
Bug 1396326 - VRDisplay.getFrameData() now returns false when orientation data is not available

Review of attachment 8912899 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/vr/VRDisplay.cpp
@@ +441,5 @@
>  {
>    UpdateFrameInfo();
> +  if ((mFrameInfo.mVRState.flags & gfx::VRDisplayCapabilityFlags::Cap_Orientation) ==
> +      gfx::VRDisplayCapabilityFlags::Cap_None) {
> +    // We must have at minimum Cap_Orientation for a valid pose.

I think using !(mFrameInfo.mVRState.flags & gfx::VRDisplayCapabilityFlags::Cap_Orientation) would be better because the flag from VRHMDSensorState is 0 in initial.
Pushed by kgilbert@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/67974008894e
VRDisplay.getFrameData() now returns false when orientation data is not available,r=daoshengmu
https://hg.mozilla.org/mozilla-central/rev/67974008894e
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Should it just ride the train? Thanks
Flags: needinfo?(kgilbert)
Comment on attachment 8912899 [details] [diff] [review]
Bug 1396326 - VRDisplay.getFrameData() now returns false when orientation data is not available

Approval Request Comment
[Feature/Bug causing the regression]:
N/A - New Feature
[User impact if declined]:
WebVR sites that expect VRDisplay.getFrameData() to return false when losing headset tracking may work erraneously.  In particular, A-Frame based scenes will spin the world erratically, resulting in an uncomfortable experience when the user leaves their tracking volume.
[Is this code covered by automated tests?]:
Yes, existing VR reftests call VRDisplay.getFrameData
[Has the fix been verified in Nightly?]:
Yes
[Needs manual test from QE? If yes, steps to reproduce]:
yes, STR:
- Start Firefox with an HTC Vive installed
- Visit https://aframe.io/examples/showcase/helloworld/ 
- Press the "Enter VR" button
- Wear VR headset
- Walk outside of the HTC Vive tracking space
- Expected result: world stops moving or fades out
- Bad result: world spins erratically
[List of other uplifts needed for the feature/fix]:
None
[Is the change risky?]:
Low risk
[Why is the change risky/not risky?]:
This is a small patch self contained within the VRDisplay.getFrameData() implementation.
[String changes made/needed]:
N/A
Flags: needinfo?(kgilbert)
Attachment #8912899 - Flags: approval-mozilla-beta?
Comment on attachment 8912899 [details] [diff] [review]
Bug 1396326 - VRDisplay.getFrameData() now returns false when orientation data is not available

Severe bug, WebVR only, low risk, Beta57+
Attachment #8912899 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Contact: cristian.comorasu
I can confirm this issue is fixed, I verified using Fx 57.0b8 and Fx 58.0a1 ( build ID: 20171013100112), on Windows 10 x64, Oculus Rift.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.