Closed
Bug 1254776
Opened 9 years ago
Closed 8 years ago
[webvr] `VRDisplay.requestPresent` must succeed when called from only from a user-gesture or trusted event
Categories
(Core :: WebVR, defect)
Core
WebVR
Tracking
()
RESOLVED
FIXED
mozilla55
Tracking | Status | |
---|---|---|
firefox55 | --- | fixed |
People
(Reporter: kip, Assigned: kip)
References
()
Details
(Whiteboard: [webvr])
Attachments
(1 file, 1 obsolete file)
Although the new WebVR 1.0 API (https://mozvr.github.io/webvr-spec/) no longer users the "RequestFullScreen" method to enter VR, we will need a permission prompt for the user to accept before resolving the promise returned by Navigator.getVRDisplays(). This will ensure that users can not be uniquely identified and tracked using the WebVR API’s unless they are opting in to a VR experience.
If there are no VR Displays, the promise should resolve immediately without any users prompts.
If there is at least one VR Display enumerated, the permission prompt should be displayed. No VR Devices should be returned by the resolved promise unless the user accepts the request to access their VR hardware.
If already in VR, either due to a previously accepted prompt on the page or when following a link between VR sites, the permission prompt should be suppressed.
This behavior should be reviewed by Mozilla’s security team to ensure that it is sufficient to protect user’s identity.
Kip, the CV1 has a presence sensor on it. We should be able to avoid any permission prompts at all since the user only really activates the headset when it is put on. Thoughts?
Flags: needinfo?(kgilbert)
Assignee | ||
Comment 2•9 years ago
|
||
Interesting find Casey. We can indeed query the status of the presence sensor in the 1.3 Oculus SDK. I feel we could bypass this prompt if the user is wearing the headset; however, it would still need to appear for cases when the headset isn't being worn yet or for devices without the sensor. Perhaps the permission prompt would also be skipped if the user is launching Firefox from the Oculus Home or SteamVR...
Flags: needinfo?(kgilbert)
I think in the case where the user isn't wearing the headset yet, it would prompt them to do so, rather than displaying a prompt.
I also agree that when launched from Oculus Home or SteamVR, the prompt is not needed (since you are already in the headset)
Comment 4•9 years ago
|
||
I can take care of this one guys.
Just to confirm.
1. Do not prompt if the user has the headset on (https://developer.oculus.com/doc/1.3.0-libovr/_o_v_r___c_a_p_i_8h.html#a51417734701f25e88bc7451c6f4be4fa)
2. Prompt the user to put the headset on to continue. Poll for further status. Once it's on, automatically go to Fullscreen and continue.
The implementation of the prompting would go somewhere here -- http://mxr.mozilla.org/mozilla-central/source/gfx/vr/ipc/VRManagerChild.cpp#178 (or in a method called from there). We could also consider putting it in Navigator.cpp itself but that seems like clutter.
Prompting can be done via nsIPromptService.
Sound good?
Assignee: nobody → aus
Status: NEW → ASSIGNED
Comment 5•9 years ago
|
||
Based on the original description, we would also do the following --
Since it is a permission that we are granting, we should also use the Permission Manager to store the answer from the user and associate it with the URL. We can then do the same prompt, but only when the headset isn't on, then when it's on, we automatically dismiss and continue.
This should help us have minimal prompting. Only prompt for new hosts that haven't asked for VRDevices yet, and only prompt when the HMD isn't on the users head.
Assignee | ||
Comment 6•9 years ago
|
||
That sounds great, Aus! I'd be glad to help you navigate the VR code if you need a hand. Thanks for taking this one.
Some ideas on handling the sensors...
For the headset state, not all devices will be able to detect if you are physically wearing it or not. There would be some initial states:
1. Already in VR
- No prompt is needed, can immediately resolve the promise.
2. Not in VR and have sensor confirming that headset is not being worn
- Display prompt until the sensor confirms that headset is being worn or the user presses "Ok", then resolve the promise.
3. Not in VR and have sensor confirming that headset is being worn
- No prompt is needed, can immediately resolve the promise.
4. Not in VR and don't have a sensor to check when headset is worn
- Display prompt until the user presses "Ok", then resolve the promise.
In any event, if the user cancels the prompt without pressing "ok" or a sensor can't detect the headset being worn, the promise should resolve a failure condition.
Comment 7•9 years ago
|
||
Wanted to get a little feedback before I add the final bits of code that checks the focus caps and state and prompts when appropriate. :)
Attachment #8743586 -
Flags: feedback?(kgilbert)
Assignee | ||
Comment 8•9 years ago
|
||
This looks great so far, thanks! I'd be glad to help if you have any questions as things move along..
Assignee | ||
Updated•9 years ago
|
Attachment #8743586 -
Flags: feedback?(kgilbert) → feedback+
Assignee | ||
Comment 9•8 years ago
|
||
After discussion with Chromium WebVR team, we would like to avoid a prompt and rather require entering VR to be within a user gesture. This requirement only applies to entering VR from a 2d site. Traversing links between WebVR sites does not require a user gesture.
Assignee | ||
Updated•8 years ago
|
Summary: [webvr] Implement WebVR Permission Prompt → [webvr] VRDisplay.requestPresent must only succeed when called from a user gesture
Comment 10•8 years ago
|
||
That seems more appropriate, I had something working but it was actually pretty clunky feeling with a prompt. This should feel better.
Did we have a gesture in mind? As simple as clicking a link?
Assignee | ||
Comment 11•8 years ago
|
||
This behavior has been further refined in the WebVR spec.
Essentially, we do not wish to have a permission prompt in any case. The VRDisplay.requestPresent call must be called from within a trusted event. Events triggered by user gestures (clicking a mouse for example) are considered trusted as well as the newly defined "onvrdisplayactivate" event:
https://w3c.github.io/webvr/#interface-window
"onvrdisplayactivate" will trigger by a sensor in the headset that detects that the user has put on the headset, during link traversal from a page that was presenting in the headset, or during page refresh.
If a script called VRDisplay.requestPresent outside of one of these trusted events, the returned promise will resolve failed and the call will have no effect.
Essentially, the user would click on a button to enter VR the first time, but could stay in vr continuously through link traversal and page refresh
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Comment 12•8 years ago
|
||
A preference and a command-line flag should be added to allow this requirement to be disabled for the purposes of automated testing and exceptional web developer use cases.
Chrome will be shipping with a command-line flag:
--disable-gesture-requirement-for-webvr
Updated•8 years ago
|
Summary: [webvr] VRDisplay.requestPresent must only succeed when called from a user gesture or trusted event → [webvr] `VRDisplay.requestPresent` must succeed when called from only from a user-gesture or trusted event
Assignee | ||
Comment 13•8 years ago
|
||
Once Bug 1313239 lands, we can make VRDisplay.requestPresent require a trusted event.
I'll take this bug and implement this requirement. It will include a preference to bypass the requirement, to enable unattended tests to execute.
Assignee | ||
Updated•8 years ago
|
Assignee: aus → kgilbert
Comment hidden (mozreview-request) |
Assignee | ||
Updated•8 years ago
|
Attachment #8743586 -
Attachment is obsolete: true
Comment hidden (mozreview-request) |
Assignee | ||
Updated•8 years ago
|
Attachment #8840204 -
Flags: review?(kyle)
Assignee | ||
Updated•8 years ago
|
Component: General → WebVR
Product: Firefox → Core
Comment 16•8 years ago
|
||
mozreview-review |
Comment on attachment 8840204 [details]
Bug 1254776 - VRDisplay.requestPresent must succeed only when called from a user-gesture or trusted event
https://reviewboard.mozilla.org/r/114706/#review119736
Attachment #8840204 -
Flags: review?(kyle) → review+
Comment 17•8 years ago
|
||
We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again.
hg error in cmd: hg rebase -s fe123e648bd1 -d 1112d053e282: rebasing 379964:fe123e648bd1 "Bug 1254776 - VRDisplay.requestPresent must succeed only when called from a user-gesture or trusted event r=qdot" (tip)
merging dom/vr/VRDisplay.cpp
merging dom/vr/VRDisplay.h
merging gfx/thebes/gfxPrefs.h
merging modules/libpref/init/all.js
warning: conflicts while merging gfx/thebes/gfxPrefs.h! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
Comment 18•8 years ago
|
||
Pushed by kgilbert@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/733e8e23f8a1
VRDisplay.requestPresent must succeed only when called from a user-gesture or trusted event,r=qdot
Comment 19•8 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in
before you can comment on or make changes to this bug.
Description
•