New issue
Advanced search Search tips

Issue 694772 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug
Proj-VR
Proj-XR



Sign in to add a comment

Reset pose button fails when viewer changed from daydream to cardboard

Project Member Reported by dbbrooks@chromium.org, Feb 21 2017

Issue description

Chrome Version: 57.0.2987.72
OS: 7.1.2
Platform: Pixel


What steps will reproduce the problem?
1. Set viewer type to be Daydream
2. Access https://webvr.info/samples/03-vr-3. presentation.html on the test device
3. Change viewer type to be cardboard.
4. Rotate the device vertically until it is completely vertical (i.e. the screen is directly in front of the user and not rotated)
5. Turn the test device right or left until the FPS display is no longer in view, approximately 90 degrees
6. Select the “Reset Pose” button

What is the expected result? pressing reset view button works. The content’s view has been updated so that the FPS display is now centered

What happens instead? pressing reset view button fails. The content's view doesn't change.

Note that if the page is refreshed, it works.

Just seems like it would be nice to not have to refresh the page to get this to work when viewer type has changed.
 
Cc: mthiesse@chromium.org bajones@chromium.org
Labels: -Proj-VR VR-Cardboard Proj-VR-Daydream
I'm not sure we expect things to continue to work correctly without reloading the page* if you make such a change. These headsets are exposed with different properties, so we can't just change from one to the other. Perhaps we should issue a "disconnected" event and fail to render if something like this happens.

* It's also possible that even reloading the page is not sufficient. If so, that's a separate bug we should fix.
This is actually surprising to me though. We query gvr for the current viewer type each time resetPose is called, and if it's cardboard we reset the pose. I'm not sure what state we could possibly be holding onto that would make that logic fail.

To David's point though, I'm not sure that we do actually handle a change in viewer type properly, we should do some testing on that/file bugs.
Status: Available (was: Untriaged)
Components: Blink>WebXR
Removing Blink>WebVR component and assigning to Blink>WebXR 
Components: -Blink>WebVR

Sign in to add a comment