> Specifically: I was wondering about the real impact of the webvr polyfill not working, on Firefox users. My mention of the work implementing WebVR was pointing out that we will hopefully not need to worry about the webvr-polyfil working on Gecko-based browsers in the not-to-distant future, whenever we have full platform coverage for a real WebVR/WebXR implementation.
My ideal here is that we have an explicit user action / gesture or prompt for: Magic window, WebVR/XR and device orientation. We might choose to make several prompts rolled into one for VR but ultimately it will still require the user to understand the risks. I'm not really sure there is an obvious way of protecting the user from magic window being just as dangerous as device orientation. > if we’re including iOS in the list of platforms we may want to try and remove device orientation from I don't think we need to remove it just provide UI in the short term to require the user to approve. > when WebXR (including “Magic Window” support) will ship in all versions of Firefox I'm unsure here too, I'm not after restricting these websites from working at least in the short term. I think the functionality should still exist if we can come up with the right controls to these APIs. I suspect we are mostly talking about fennec but I'm also not sure if any laptops/tablets use these APIs if the sensors exist. If the APIs are in use again I think the prompts should be clear to the user about the risks they have. One thing that we could try is taking the user though an on-boarding tutorial when they first see a website that uses this API. The tutorial could explain to them what the API will be called, how they will be prompted and what the risks are to them. On Thu, Jan 11, 2018 at 6:15 PM, Blair MacIntyre <bmacint...@mozilla.com> wrote: > Oh, I see what you are saying. I think there is some confusion here > (perhaps on my part only). > > I do not know if the main use of (and motivation for) the sensor APIs is > webvr, but I have not been involved in it. I thought that (newer) API was > brought up in this discussion as a suggestion for a replacement for the > deviceorientation APIs. (Again, I’m unaware of the history or motivations > behind that API.) > > There has been some supposition in this discussion that the main use of > the device orientation APIs is the WebVR polyfill. I do not know if that > is true, I don’t think Chris or I said that — I haven’t seen any mention of > any data to support or not support that. It is clear that _a_ use of the > device orientation APIs is supporting WebVR polyfill. But it also used > for panoramic photo viewers, 360 video viewers, and probably other > (legitimate) things. Regardless, I fully understand the security/privacy > concerns. > > My message this morning was intended to (perhaps) reframe the discussion > and (perhaps) let us move forward. Specifically: I was wondering about > the real impact of the webvr polyfill not working, on Firefox users. My > mention of the work implementing WebVR was pointing out that we will > hopefully not need to worry about the webvr-polyfil working on Gecko-based > browsers in the not-to-distant future, whenever we have full platform > coverage for a real WebVR/WebXR implementation. > > What is/was unclear to me is: > - if we’re including iOS in the list of platforms we may want to try and > remove device orientation from. Matters insofar as we WON’T be able to > implement WebVR/WebXR there. > - when WebXR (including “Magic Window” support) will ship in all versions > of Firefox. I could “guess” but that’s not useful (I have no control over > that). > > But, if we laid out a plan that said “in the short term we’ll do X, which > may not be ideal, when WebXR is available we’ll do Y”, that might help. I > hope that the second step is not too far in the future, but thinking of it > that way at least doesn’t lock us into “we need to find a satisfactory > solution that keeps the webxr-polyfill working indefinitely” since it > doesn't need to work indefinitely. > > Please forgive me for the lack of clarity. And, of course, if that sort > of approach isn’t acceptable, just say so. > > > > On Jan 11, 2018, at 12:53 PM, Anne van Kesteren <ann...@annevk.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? > > > > That if our main usage for the new sensor APIs (those discussed in > > https://github.com/w3ctag/design-reviews/issues/207) is WebVR/XR and > > we don't have any other uses that are compelling enough, and WebVR/XR > > will come with their own APIs for this, there's no reason for us to > > worry about the new sensor APIs. > > > > > > -- > > https://annevankesteren.nl/ > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
