My hope is that any stickiness would be transitory. If someone is obviously using a VR headset, I don't think we would require much movement at all to trigger the automatic permission. That's clearly a primary input interface.
On Thu, Jan 4, 2018 at 9:15 PM, Blair MacIntyre <bmacint...@mozilla.com> wrote: > I’m unclear of which side of the line we want to fall on between supporting > existing sites or requiring them to change. > > If we are going to break existing websites, then perhaps looking at the > Generic Sensor API (as CVan suggests in his email) is a more rational > approach; is it implemented in FF yet? Plans for it? > > For device orientation, my assumption (perhaps incorrect?) has been that we’d > be trying to support existing sites. The worry I have with the gross motion > idea is that the UX would be terrible. Right now, you start a site (VR, 360 > image, etc) and can look around: in my own experience, the motion is rarely > fast. So the site would appear stuck, and the user may never discover it’s > stuck. > > But, perhaps if we’re willing to change the browser itself to provide some > feedback, this could work though. > - I go to a site, it requests motion > - motion events are not sent initially > - FF waits a bit to see if the user shakes or grossly moves the phone (e.g., > perhaps a newer site says “shake the phone to activate panoramic viewing”) > - if it does happen, FF slides in/down a message saying something similar > (e.g., “site wants to watch the movements of your device; shake phone or > click yes to confirm, no to deny”) > - if shake doesn’t happen in short time, or they click no, that’s that. If > they shake or click yes, motion is used. > > But, perhaps this is too confusing. > > For the perms API, I imagined it might just work with devicemotion: setting > up the callback could trigger a perms request, and the data would only start > flowing on acceptance. > >> On Jan 3, 2018, at 11:52 PM, Martin Thomson <m...@mozilla.com> wrote: >> >> On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre <bmacint...@mozilla.com> >> wrote: >>> We could chat about it, sure; how do you envision it working without >>> breaking old websites? >> >> With the understanding that this is purely spitballing... >> >> We would stop providing events (or provide them with extremely low >> frequency [1]), but if the currently focused context has an event >> handler registered for orientation events, we would enable events once >> the orientation changes by a large amount or quickly. The thresholds >> might need some tuning, but a shake or large movement should work. >> >> That means that sites that expect and only receive subtle movement >> would stop receiving events. Sites that don't receive input focus >> would stop receiving events (that prevents an embedded iframe from >> getting events). But sites that legitimately use the API will only >> appear to be a little "sticky" initially. We might also persist this >> "implicit" permission to remove that stickiness for sites that are >> used often (or reduce the activation thresholds over repeat visits). >> >> We should also look at getting a hook into the permission API so that >> the current state can be queried. But that API doesn't really >> understand this sort of model, so that might be tricky to work out. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
