Re: Device Orientation API future

ors to build models of the world around the user, for example), we will eventually want to explore how to expose that data into the web (as part of WebXR, or some other API). Explaining what this means to users will be hard, much like device orientation. Thanks for your patience with all of t

Re: Device Orientation API future

evk.nl> wrote: > > On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >>> In that case I'm not entirely sure why we'd also pursue new >>> variants separately. >> >> I’m not sure what this means? > > Tha

Re: Device Orientation API future

> On Fri, Jan 12, 2018 at 4:48 AM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >>> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre <bmacint...@mozilla.com> >>> wrote: >>>> First, this discussion pertains to FF on Windows, Mac, Android an

Re: Device Orientation API future

> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >> First, this discussion pertains to FF on Windows, Mac, Android and Linux, I >> assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide >> on things like

Re: Device Orientation API future

I’ve been thinking about this since my last message, and I wanted to step back and clarify something for myself. First, this discussion pertains to FF on Windows, Mac, Android and Linux, I assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide on things like this. Is this

Re: Device Orientation API future

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 ch

Re: Device Orientation API future

We could chat about it, sure; how do you envision it working without breaking old websites? > On Jan 3, 2018, at 5:43 PM, Martin Thomson <m...@mozilla.com> wrote: > > On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >> I was

Re: Device Orientation API future

don't think that is a far > stretch from head/position tracking. > > On Wed, Jan 3, 2018 at 2:47 PM, Blair MacIntyre <bmacint...@mozilla.com > <mailto:bmacint...@mozilla.com>> wrote: > I don’t think tying orientation to GPS is really a viable approach. > > Th

Re: Device Orientation API future

I don’t think tying orientation to GPS is really a viable approach. The main use case for the orientation API, I think, is not AR; it’s 360 images and videos, and “cardboard VR”, right now. > On Jan 1, 2018, at 5:01 PM, Martin Thomson wrote: > > The suggestion that was

Re: Device Orientation API future

(I’m CC:ing a few of the MR team folks, although I’m sure many of them are on the dev-platform list already). Speaking for myself (not the official stance of the WebVR team), I share these concerns and like the trajectory you suggest. I would HOPE that in the long run (some number of years?)

Re: Device orientation/motion events privacy issues

>>> We discussed this a bit with Anne on IRC. It seems like this API is a good >>> use case for a permission prompt to the user. Since the API works by >>> registering an event listener, the only realistic option seems to be >>> Permission.request() before registering the event listeners.

Re: Device orientation/motion events privacy issues

>> What's the reason for this? I don't know for sure, but it may be necessary >> for things like AR/VR to have higher resolution than that. > The reason is to limit the frequency of sensor data the web application > receives to allow it to guesstimate the changes to the device position to >

Re: security problems [WAS: Intent to remove: sensor APIs]

> At least these things should be purely optional and providing an > *easy* way to filter that data. (same for the geolocation stuff). FWIW, I wouldn’t mind being involved in a discussion about this, if people want to seriously consider putting it behind a "user-permission prompt" (similar to

Re: Intent to remove: sensor APIs

> On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >> Are we still talking about deviceorientation? > > As I said twice and Frederik repeated, we're not, other than asking if > anyone has a plan for how to make it interoperable

Re: Intent to remove: sensor APIs

Are we still talking about deviceorientation? It’s used to determine the 3D orientation of the device, so that we can tell the direction it is facing. Developers use it to render 3D graphics (WebGL or CSS3D using perspective DIV) around the user. e.g., look at one of my project samples, like

Re: Intent to remove: sensor APIs

I’m not sure what you’re asking: I’ve been using the deviceorientation API like this for many years, as have plenty of other people.It’s absolutely needed. -- Blair MacIntyre Principal Research Scientist bmacint...@mozilla.com <mailto:bmacint...@mozilla.com> > On Jul 24, 2017

Re: Intent to remove: sensor APIs

On Jul 24, 2017, at 4:38 PM, Enrico Weigelt, metux IT consult wrote: > > On 24.07.2017 15:07, Mike Hoye wrote: >> >> I have a sense that as AR gets richer and more nuanced that ambient > > Are we still talking about browsers ? Yes. There are plenty of websites

Re: Intent to remove: sensor APIs

independent of WebAR? Especially when we think of issues discussed on this thread (e.g., threat models and security) having “things needed for AR” folded into WebAR, and accessible in the context of whatever permission model WebAR ends up using may be the way we want to go. -- Blair MacIntyre

Re: Intent to remove: sensor APIs

I was just about to say the same thing. This API is essential for our AR work; the fact that Firefox is different than other browsers is problematic, but there are javascript libraries that help with it. Getting rid of it would be really bad. > On Jul 24, 2017, at 9:57 AM, Ben Kelly