Position of headset incorrect (too high) after refreshing the page and entering VR with onvrdisplayactivate handler

RESOLVED INVALID

Status

()

Core
WebVR
P3
normal
RESOLVED INVALID
10 months ago
9 months ago

People

(Reporter: Kevin Ngo, Unassigned)

Tracking

56 Branch
Points:
---

Firefox Tracking Flags

(firefox57 affected)

Details

(Reporter)

Description

10 months ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

1. Go to a VR-enabled page (not in an I-Frame) that handles onvrdisplayactivate.
2. Enter VR.
3. Refresh the page.


Actual results:

The page maintains VR mode. The height of the headset is too high (by about a couple of meters). The position of the controllers are correct. The headset and controllers still track.


Expected results:

The page maintains VR mode. The height of the headset and controllers match the real world position.
(Reporter)

Comment 1

10 months ago
On Firefox Developer Edition 56.0b11 (64-bit)
Version: unspecified → 56 Branch

Comment 2

10 months ago
Could you try opening this page in another tab while doing your STR?

https://webvr.info/samples/00-hello-webvr.html

Before and after refreshing the page in your STR, do the values of "sittingToStandingTransform" change or pose/position show a translation that would account for the offset?

This may help us to bisect the problem between possible bugs in the browser or content.
status-firefox57: --- → affected
Flags: needinfo?(ktngo09)
Priority: -- → P3
I encounter this kind of issue and can be resolved by using a new profile. It seems to make browser.tabs.remote.autostart.2;true could this problem. Please help us take a try. Thanks.
(Reporter)

Comment 4

10 months ago
So it was not an issue with the pose or transform data, and new profile didn't do anything. It was intermittent, but the suspicion is that we enter VR early using the `vrdisplayactivate` event, we grab the VR display, and check for `vrDisplay.capabilities.hasPosition` to determine if we are on room scale, we remove a default 1.6 meter height offset which we use for 3DoF/2D mode.

So possibly, the VR display's `capabilities.hasPosition` is not set soon enough. For a workaround, I suspect adding a timeout before doing that VR display check will fix things.
Flags: needinfo?(ktngo09)
(Reporter)

Comment 5

9 months ago
Sorry, this is an A-Frame issue where our scene entered VR before we had our event listeners attached to remove a camera offset.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → INVALID
(In reply to Kevin Ngo from comment #5)
> Sorry, this is an A-Frame issue where our scene entered VR before we had our
> event listeners attached to remove a camera offset.

Thanks for tracking this down, Kevin!
You need to log in before you can comment on or make changes to this bug.