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
