Closed Bug 1121626 Opened 9 years ago Closed 9 years ago

Disable fullscreen permission prompt when requestFullscreen({vrDisplay: vrHmd})

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: caseyyee.ca, Assigned: vlad)

References

Details

(Whiteboard: [webvr])

Attachments

(2 files)

Attached image permission.jpg
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2275.0 Safari/537.36

Steps to reproduce:

Make sure your VR Headset is plugged in and working in extended mode, then:
1. Download and install Nightly
2. Download and install VR add-on
3. Navigate to: http://mozvr.github.io/vr-web-examples/threejs-vr-boilerplate/
4. Double click anywhere in the window to enter VR.




Actual results:

The window is sent to the VR headset where the user is then presented with a fullscreen permission prompt.  The user must accept the permission before they can interact with the content, but this is not possible from within the headset.   



Expected results:

Fullscreen and distortion effects are implicit when viewing content in a VR headset.   We should not prompt the user for permission when requestFullscreen with vrDisplay option is supplied.
Assignee: nobody → vladimir
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM
Ever confirmed: true
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
So the rationale for this is that it is much more difficult to do any UI spoofing when VR-fullscreen, because the fullscreen display will be on a VR HMD, and will have some kind of post-processing applied.  If a WebGL canvas is made fullscreen there is no requirement that the rendering will be split screen, but the post processing will be applied regardless.

Of course, the post-processing will be known, so it theoretically could be possible to render something that will look "normal" when post-processed.  I don't know how much of a concern that should be.  What do DOM/security folks think?  Is it reasonable to skip the prompt if vrDevice != null?
Attached image VR-prompt-problem.jpg
Here's a rough approximation of what the prompt looks like in the VR HMD. Barely visible at the top of the user's field of vision, text and buttons are completely off screen, and it blocks input while present.
There are two views to consider, the Desktop and the VR device. If the Desktop mirrors the VR device, as it did in the Portland demos I played with, then a clever attacker who detects you have a VR device could try to launch spoofing content on your desktop. If you are interacting with their site and nothing is yet fullscreen then you're probably not looking at the VR display.

As I understand it, the black masking that shows up on the desktop in this mirrored case is not optional and that's going to make it hard to spoof anything interesting even if you do counter the distortion. Still, it's a good idea to show the "Site foo.com is now fullscreen" overlay for a few seconds just for consistency. Won't be visible in the VR device but that's OK because it doesn't need interaction, and will help anyone still looking at the desktop just in case we're underestimating the spoofing capabilities here. This understanding is behind our decision that bypassing the fullscreen prompt was safe if it's going into VR mode (with the black masking).

[It seems unfortunate to have reused the requestFullscreen() API for VR rather than a new VR-specific API that could have had separate rules appropriate to VR.]

I don't know what to do about spoofing in the VR device itself. I don't think we've invented enough of a user-interaction model to know what might be spoofed in the future. To the extent the interaction is
 * browse to a VR demo site in your desktop
 * click the "try VR" button
 * put on your headset
there's not much opportunity for spoofing: The site you're on is completely responsible for all the content and you know what site you just visited. Obviously that's not an entirely satisfactory experience and people will want to navigate while in VR. We can't know what kind of spoofing to prevent until we know what kind of navigation signposts we're going to have. One thing that will probably work no matter what UI we have is some event that brings up a HUD showing what site you're on, and make sure the event can't be captured by the web content itself. That's the idea behind "ESC closes fullscreen" in videos, though we may want something else (do the VR devices themselves have any consistent buttons that could be used?).

I wouldn't worry too much about VR spoofing yet, just make sure VR can't be used to spoof the Desktop.
Flags: sec-review+
How difficult would be to implement this? If I see a clear path to get it done I might bite the bullet and try to do it myself. Being able to render VR content without any additional user action is key to the user experience. VR should load within the headset just by visiting a site that contains VR content (the site has to still invoke requestFullscreen with the headset as a parameter). 

I want to use the headset display in extended mode (no mirroring with desktop). This way dev tools will remain functional in the main display while VR content is displayed within the headset. We will have a compelling development story where the user does not have to leave VR mode to create content. You would be able to use the DOM Inspector, the JS console or your IDE, reload the page and get your VR scene updated.
 
Websites will be also able to offer two different experiences: their traditional web content rendered on the main display and a "VR experience" rendered only when a headset is present. I can easily imagine a lot compelling use cases of VR enhanced sites without having to change current content. For instance, Wikipedia could enhance content with small VR experiences to complement certain articles. It could be also used as a marketing or promotional tool. Imagine redbull.com shipping a Felix Baumgartner stratospheric jump VR experience. Those small bitesize experiences fit very well in a web context where content is streamed to you without installing anything. Convincing people to install a native app just for a one time 1-2 mins experience will be a much harder sell.
Flags: needinfo?(vdjeric)
Flags: needinfo?(kgilbert)
Flags: needinfo?(vdjeric) → needinfo?(vladimir)
Blocks: 1182132
Whiteboard: [webvr]
Can we just turn the fullscreen prompt into a doorhanger prompt, if vrDisplay != null is passed to requestfullscreen?  That seems like the easiest thing to do here, and probably the most functional as well.
Flags: needinfo?(vladimir)
We are currently removing all permission prompt for fullscreen in bug 1160017.
Depends on: 1160017
As VR content is always fullscreen on the HMD, I agree with :vlad on using just a doorhanger prompt.

When future OS's begin to natively support HMD's and display OS dialogues, then we will potentially need to consider something like a "modal vs non-modal" permission request.  So far, there is no concept of what this OS level interface for HMD's will look like or what the security model will require.
Flags: needinfo?(kgilbert)
Mark this as fixed as all fullscreen permission prompt has been removed in bug 1160017.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: