Open
Bug 1392806
Opened 7 years ago
Updated 2 years ago
VRDisplay.getFrameData needs to fail when not called within a VRDisplay.requestAnimationFrame callback
Categories
(Core :: WebVR, defect, P3)
Core
WebVR
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox57 | --- | affected |
People
(Reporter: kip, Unassigned)
Details
The WebVR 1.1 spec states that VRDisplay.getFrameData should return false and not update the VRPose values when not presenting. Firefox needs to enforce this requirement to further reduce the fingerprinting surface area. Using getFrameData when not presenting is a convenient tool for developers, so this should be behind a pref that can be overridden.
Reporter | ||
Comment 1•7 years ago
|
||
This reduces our fingerprinting surface area and makes us more conformant with the WebVR 1.1 spec; however, would have a noticeable effect on WebVR sites that let you move the headset around to adjust the point of view before presenting. I intent to land this behind a pref that devs can override. Perhaps we could land this in two parts.. First stage has the code in place, but the pref still allows getFrameData calls outside of presentation. Second stage changes the pref default to match the spec.. Once the first stage has been implemented, perhaps we could get some testing on sites to check for regressions that would hit when the pref default changes.
Reporter | ||
Updated•7 years ago
|
status-firefox57:
--- → affected
Priority: -- → P3
Reporter | ||
Comment 2•7 years ago
|
||
As per the WebVR 1.1 spec, getFrameData must require both a presentation and be called within a VRDisplay.requestAnimationFrame callback
Summary: VRDisplay.getFrameData needs to fail when not presenting → VRDisplay.getFrameData needs to fail when not called within a VRDisplay.requestAnimationFrame callback
Reporter | ||
Comment 3•7 years ago
|
||
For OpenVR, we should additionally avoid tracking the user's head and controllers until VR presentation has started, so we can play nicer with other non-webvr content.
Comment 4•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: kearwood → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•