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

Florian Bösch pyalot at gmail.com
Wed Sep 21 09:47:58 UTC 2016


P.S.

I own 3 iOS devices. I'm by now reduced to clicking "allow google.com to
use your location" between 3 - 10x a day, sometimes multiple times in a row
because of some iframes. And that's just for this one site. I dread to
think what'd happen if I'd be inclined to use several location based
websites... I'm not saying this is malicious by Apple, or not in
conformance with the permission APIs intent. But... if I wanted to drive
people off the web as a device vendor, that's how I'd do it. Adhere to an
inherently broken specification fastidiously by the letter.

On Wed, Sep 21, 2016 at 11:39 AM, Florian Bösch <pyalot at gmail.com> wrote:

> I've gone trough developer documentations for iOS, Android and the Web and
> looked at how permissions are handled.
>
> By far and large (where feature parity is established), all three
> platforms are shifting to an "as needed" permission model and seem to
> require about the same level of interaction per feature. The problem,
> per-se, isn't that the web is asking the user for permission, apps do that
> too.
>
> The problem is the following: A survey from 2015 found that most users
> (more than half) use between 6-10 smartphone apps per week. And for the
> most part, those are the same apps they're using most of the time (it's not
> 6 different apps every week). Of course there's less and there's more, but
> that's the peak of the bell curve.
>
> There's similar surveys and studies of user behavior for websites, and the
> general direction is that while most people use 3-4 regular websites every
> day that change rarely, they also visit around 2-3 new websites every day,
> often only once.
>
> That'd be the same as the average user installing around 20 new apps on
> their smartphone every week.
>
> If users behaved that way with apps, permissions for apps would be a huge
> nightmare, as clicking away permission dialogs was one of the main
> activities that users would perform on their devices. Yet, this apparent
> disconnect in usage pattern does not seem to have given web permission
> specifiers/standard-bodies any pause.
>
> It's well documented how prompting users for permissions continually is a
> bad idea (windows vista anybody?). Yet, that's where the web is headed, due
> to its different usage pattern than native apps. Unless this is contained
> in some way, the web's in for a very bad time (tm).
>
>
>
> On Wed, Sep 21, 2016 at 11:25 AM, Chris Van Wiemeersch <cvan at mozilla.com>
> wrote:
>
>> This was indeed a topic of discussion when rewriting the WebVR API for
>> v1.0 (see this issue for example: https://github.com/w3c/webvr/i
>> ssues/30#issuecomment-223152012). Now that this requirement has shipped
>> in Brandon's builds, and this thread has gotten active, I'll chime in.
>>
>> > Without basic limits to encourage best practices even "good" sites can
>> fall into crappy and annoying behavior simply out of naivete.
>>
>> From a non-VR context, existing browsers (at least Chromium and Firefox)
>> do require what the WHATWG HTML Living Standard calls a "user-activation"
>> interaction event (https://html.spec.whatwg.org/
>> multipage/interaction.html#triggered-by-user-activation) upon requesting
>> Geolocation (`navigator.getGelocation`), entering Fullscreen
>> (`requestFullscreen`), and opening a new tab/window (`window.open`).
>>
>> As I'm sure everyone is aware, that means your API calls must happen
>> within an event listener callback for the following event types:
>>
>> * `change`
>> * `click`
>> * `dblclick`
>> * `mouseup`
>> * `reset`
>> * `submit`
>>
>> Events fired from content do not count. The browser must be fire a
>> "trusted" event (which will be fired upon a true user-activated gesture).
>>
>> It is true that there are no browser flags (to my knowledge) that allow a
>> developer to disable this restriction. But, I'd reckon though that this
>> user-gesture requirement for VR presentation is closer to the one required
>> by Chromium (and WebKit) for media playback.
>>
>> From chrome://flags/#disable-gesture-requirement-for-media-playback:
>>
>> > Gesture requirement for media playback (Mac, Windows, Linux, Chrome OS,
>> Android)
>> > User gesture requirement for playing media elements. Disabling this
>> will allow autoplay to work.
>>
>> What I'm suggesting is that, yes, I also agree that Chromium, Firefox,
>> Edge, etc. should introduce flags to disable the requirement that gates VR
>> presentation on the user gesture. It will be immensely helpful for
>> development, testing, and native bundling when dealing with webviews and
>> browser runtimes (i.e., those dependent on Chromium, such as Crosswalk and
>> Electron).
>>
>> I know Chrome for Android requires a user gesture for media playback,
>> but, FWIW, Firefox for Android does not (and will soon not in Firefox for
>> iOS as well). But, we do have settings for the user to disable autoplay of
>> media from user settings in both mobile versions of Firefox, if the user
>> decides sites are annoying them. (Could go so far as to add a blacklist, or
>> even go the route of the Permissions API, but I haven't heard a need for it
>> - though I may be missing some stories.)
>>
>> Chrome for Android could possibly rely on "user-initiated gesture" as an
>> orientation change when a user's device rotates from portrait to landscape (
>> https://w3c.github.io/screen-orientation/#dfn-triggered-by-
>> a-user-generated-orientation-change).  Admittedly though, I'm not privy
>> to whether this is desirable or even feasible from a UX/tech POV for the
>> case of Google Daydream.
>>
>> Michael gives some good suggestions about possible solutions, which I
>> know have been brought up in the spec discussions - detecting when the
>> headset is on a user's head (I know at least the Rift, Vive, and Gear VR
>> all expose this info. from their APIs). A counterargument brought up was
>> that even if no other content is being presented to the user *and* the
>> user's WebVR-compatible browser is in the foreground, that doesn't
>> necessarily mean the user consented to have VR content presented to the
>> headset being worn (by the user/whomever's wearing it).
>>
>> We can continue to discuss the user-gesture requirement (especially on
>> desktop, where it can be quite bothersome), but for the sake of keeping the
>> discussions all in the same place, we probably out to keep the discussion
>> in https://github.com/w3c/webvr/issues (or https://lists.w3.org/Archives/
>> Public/public-webvr/).
>>
>> Anyway – and this is a question for Brandon and Kip – can we introduce a
>> `disable-gesture-requirement-for-vr-presentation` flag to Chromium (à la
>> `disable-gesture-requirement-for-media-playback`) and a similar flag to
>> Firefox flag when Firefox adds the same user-gesture requirement?
>>
>> > > 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?
>> >
>> > 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.
>>
>> FYI, the Permissions API shipped in Chrome 43 and Firefox 46 (docs:
>> https://developers.google.com/web/updates/2015/04/permission
>> s-api-for-the-web; https://developer.mozilla.org/
>> en-US/docs/Web/API/Permissions_API). The APIs that have adopted the API
>> (forgoing proprietary user-agent permissioning mechanisms), to my
>> knowledge, are Geolocation, Notifications, Push, and the Web MIDI APIs. The
>> complete list of APIs is here: https://w3c.github.io/permissi
>> ons/#permission-registry
>>
>> Surfacing browser UI (cert errors, infinite redirect loops,
>> alert/prompt/confirm dialogs, UI for Permissions API interactions, etc.) is
>> definitely a bridge we'll have to cross. But, I'll let Brandon and Kip
>> speak to the scope and timeline that we should commit to for WebVR v1.x.
>>
>>
>> On Tue, Sep 20, 2016 at 11:01 PM, Brandon Jones <bajones at google.com>
>> wrote:
>>
>>> 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
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> 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/1b61314f/attachment-0003.html>


More information about the web-vr-discuss mailing list