[webvr] Why does entering VR need to be on user interaction?

Brandon Jones bajones at google.com
Wed Sep 21 06:01:21 UTC 2016


I don't imagine that being in VR is going to change the thinking on any
existing APIs permission mechanisms, but if there turns out to be a really
compelling reason to re-think the way we handle one API or another when the
user is in VR I'm happy to follow that up with the appropriate teams. None
come to mind at the moment.

On Tue, Sep 20, 2016 at 10:57 PM Florian Bösch <pyalot at gmail.com> wrote:

> Correlated question. Do we have a confirmitis mechanism for when users are
> in VR and a site requests additional capabilities, such as getting a users
> location?
>
> On Wed, Sep 21, 2016 at 5:12 AM, Brandon Jones <bajones at google.com> wrote:
>
> I think "refresh while in VR" should fall under the same behavior as
> "navigate to a new page while in VR". Definitely seems like a scenario that
> you should be able to present from automatically.
>
> And, again, this isn't just something that affects theoretical devices.
> This affects mobile devices right now, as well as VR browsers like the
> Samsung Gear VR one. And of course crappy pages can find ways to abuse it.
> That's why they're crappy sites and why we avoid them. Without basic limits
> to encourage best practices even "good" sites can fall into crappy and
> annoying behavior simply out of naivete.
>
> On Tue, Sep 20, 2016, 7:59 PM Michael Chang <flux.blackcat at gmail.com>
> wrote:
>
> Thanks Kip, those solutions sound pretty good actually.
>
> For this use case, the onvrdisplayactivate event will fire on the page
> after it is loaded with a reason value indicating that there is a VR to VR
> link traversal.  Within this event, the page can enter VR without a user
> interaction as the link traversal itself is sufficient.
>
>
> So basically, sites which expect to be visited from another VR experience
> can check this, and auto-enter VR? That's great. And if the flag is
> incorrect, disallow auto-enter VR, right?
>
>
> Perhaps we could adjust the spec to include refreshing a WebVR site as one
> of the "reason" values that is passed to onvrdisplayactivate...  would that
> solve the issue?
>
>
> Actually, I think it would solve the issue. The issue, purely from a dev
> perspective, is the browser gating me nonsensically *while* developing. It
> makes no sense having to be protected by VR ads while I'm developing for VR
> content. So, if having to hit "enter VR" for the very first time (and never
> again so long as I reload) in a session is a compromise, I'd take it.
>
>
> Right. Your *current* HMD is hanging around your desk somewhere. But your
> *future* HMDs are probably going to look a lot more like HoloLens: Self
> contained devices with no external monitor. We still want a browser in this
> environment, and we still want WebVR. So now that mildly annoying ad
> doesn't just light up your HMD while you're not wearing it. It takes over
> your entire field of view without your consent and at any moment, and is
> allowed to re-take-over your display repeatedly. Does this still sounds
> like a Bizarro thing to be afraid of?
>
>
> I get your reasoning Brandon I just don't buy it ;) I guess you're
> developing an API for devices which don't exist yet and hey, cool that's
> forward thinking. But at the cost of introducing issues *now*, with
> existing hardware and software with no work-arounds is a bummer. Even a
> flag in chrome that says "I'm an adult I don't care about VR ads" would be
> great.
>
>
>
> On Tue, Sep 20, 2016 at 7:04 PM, Kip Gilbert <kgilbert at mozilla.com> wrote:
>
> Hi Michael,
>
> Perhaps I can help answer some of these...
>
> On Sep 20, 2016, at 6:20 PM, Michael Chang <flux.blackcat at gmail.com>
> wrote:
>
> In the latest chromium build:
>
> VrDisplay.RequestPresent must happen in a user gesture. (Click, touch,
> etc.)
>
> If you want the page to automatically enter VR (say, from a settimeout),
> you get this error now
>
> Uncaught (in promise) DOMException: API can only be initiated by a user
> gesture.
>
>
> I want to understand the thought process behind this decision.
>
> To my understanding, Chrome requires user interaction to go Full Screen
> because some old person might get tricked into thinking the browser is now
> their OS and they're entering their credit card to phishing, which is a
> security concern.
>
> Am I wrong that is the only reason? How is that relevant to VR though? Why
> is a user gesture required to enter VR?
>
> The rationale is that we wish to protect users from scripts in pages such
> as ads that wish to take over your VR session.
>
>
> *I want to argue that adding an extra button press to enter VR is bad
> friction on both user and developer end.* I know it sounds minor, and
> probably a crap ton of hand holding
> do-not-put-your-hands-and-legs-outside-of-the-vehicle decision making that
> goes into making Chrome, but it worries me a lot.
>
> On the User End
> Recall the wonderful discussion we had in the other thread about the
> future of VR, and building the metaverse and linking to other pages which
> are also VR. How incredibly bad would that user experience be if every time
> you link somewhere in VR, you have to take off your headset, go back to
> your desk and find the mouse, then click on enter VR, in which every
> website might have a different way of doing so?
>
>
> For this use case, the onvrdisplayactivate event will fire on the page
> after it is loaded with a reason value indicating that there is a VR to VR
> link traversal.  Within this event, the page can enter VR without a user
> interaction as the link traversal itself is sufficient.
>
>
> On the Developer End
> From a developer's perspective, it's bad enough we have to constantly take
> our headsets off and on just to find out what's going on inside there. Take
> for example, Unreal Engine's VR developer mode being really awesome because
> it knows when you've taken off or on the HMD
> <https://www.youtube.com/watch?v=cZJmh881FCo>. This is developer
> friendly, there's very little friction between the editor and entering VR.
>
> I don't know how you guys develop VR and I've tried several methods to
> make it friction free.
>
> My VR Development Style
> My first method is developing in HMD all the time, using a combination of Virtual
> Desktop <http://store.steampowered.com/app/382110/> launching chromium
> and having its home page be localhost:8000 and a voice command to reload
> the page. This is neat because I can still type in Sublime Text in VR, and
> still see WebVR live-reloading and everything still works.
>
> My current method is having a setTimeout automatically enter me in VR (1
> second after page reload) and I just have the HMD on my head and pull it
> down when I need to see something, and just hit reload. This method no
> longer works.
>
> Perhaps we could adjust the spec to include refreshing a WebVR site as one
> of the "reason" values that is passed to onvrdisplayactivate...  would that
> solve the issue?
>
>
> So what do I do now? I guess I can bind a Vive button to enter VR? How
> janky is this? Why do we have to do these hacks to enter VR, when WebVR is
> about VR content and having to worry about how to enter VR is just friction
> that shouldn't be there?
>
> Would it help to have a "Dev mode" or such switch for exceptional cases?
>
>
> Please, if anyone has insight, power to roll back this decision, or just
> want to discuss this issue, hit reply below.
>
> _______________________________________________
> web-vr-discuss mailing list
> web-vr-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/web-vr-discuss
>
>
> Thanks for the feedback!  For the Firefox implementation, would you have
> any particular wants to include in upcoming WebVR devtools?
>
> Cheers,
>   Kearwood "Kip" Gilbert
>
>   Mozilla VR Team
>
>
> _______________________________________________
> web-vr-discuss mailing list
> web-vr-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/web-vr-discuss
>
>
> _______________________________________________
> web-vr-discuss mailing list
> web-vr-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/web-vr-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/web-vr-discuss/attachments/20160921/1f75d660/attachment-0003.html>


More information about the web-vr-discuss mailing list