Intent to ship: WebVR on Windows in Release

[kgil...@mozilla.com]

As of March 1, 2017 I intend to turn WebVR on by default on Windows.  It has been developed behind the dom.vr.enabled preference and has been enabled by default on Firefox Nightly and Dev Edition since November 2015.  Other UAs shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel.  Microsoft Edge and Google Chrome are also intending to ship.  Google Chrome has enabled WebVR on Android with an Origin Trial.

This feature was previously discussed in this "intent to ship" thread, for non-release builds:
 
https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion
 
Bug to turn on by default:
 
https://bugzilla.mozilla.org/show_bug.cgi?id=1343368
 
We will support Oculus and HTC Vive by default.  Oculus is already enabled; HTC Vive support with OpenVR has been developed behind the “dom.vr.openvr.enabled” preference and will be turned on with this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1343374

Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/

Since the initial implementation, a W3C working group was formed including members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is being conceived.
 
Windows only support for WebVR would be enabled by default in Firefox 54.  OSX is not yet supported by current VR headsets.  Beta Linux support for HTC Vive has very recently landed, and will be supported by Firefox after the Firefox 54 uplift.

Cheers,
        Kearwood “Kip” Gilbert
        :kip

[Boris Zbarsky]

On 3/1/17 3:50 PM, kgil...@mozilla.com wrote:
> As of March 1, 2017 I intend to turn WebVR on by default on Windows.

So flip the pref on Windows only, right?

If there is no VR hardware, is the idea that navigator.getVRDisplays()
returns a promise resolving to an empty array?

> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/

It's a bit worrying to me that this spec is not written down in
sufficient detail to be implemented interoperably [1]. How confident
are we that what the other browsers are shipping matches what we're
shipping? Are there web platform tests?

-Boris

[1] For example, what does the VRFrameData constructor actually do?
The spec doesn't define it at all. Where is the VRPose inside supposed
to come from? What values will it contain? I filed
https://github.com/w3c/webvr/issues/195 on this, but note that I've
spent all of about 5 minutes skimming the spec and ran into this. I
have _not_ done a careful read looking for possible interop problems...

[Andrew McCreight]

Last I looked, we didn't have any tests for VRFrameData, FWIW (bug
1317258). I see some now under servo/ but presumably we don't run those.
Maybe I'm missing some.

It would also be good to make sure our internal fuzzers are fuzzing these
APIs to at least catch basic errors.

Andrew

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Kip Gilbert]

Sent from my iPad

> On Mar 1, 2017, at 1:32 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
>> On 3/1/17 3:50 PM, kgil...@mozilla.com wrote:
>> As of March 1, 2017 I intend to turn WebVR on by default on Windows.
>
> So flip the pref on Windows only, right?

Yes, flipping pref on only for Windows. Later, we will be adding support for Linux and Android. OpenVR support for Linux is in Beta -- I would like to see Linux support come next, in Firefox 55.

>
> If there is no VR hardware, is the idea that navigator.getVRDisplays() returns a promise resolving to an empty array?

Exactly. In addition, our implementation waits until either a WebVR API is called or a WebVR event listener is added before polling underlying API's for devices.

>
>> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/
>
> It's a bit worrying to me that this spec is not written down in sufficient detail to be implemented interoperably [1]. How confident are we that what the other browsers are shipping matches what we're shipping? Are there web platform tests?

We have worked directly with the other WebVR platform implementers to ensure compatibility. We have regularly scheduled video calls and F2F meetings to improve the spec and remove any ambiguity. We have formed a W3C community working group.

A growing number of libraries and sites, including A-Frame, three.js, SketchFab, PlayCanvas, and React-VR, already support WebVR and work cross-platform.

Automated web platform testing support is landing imminently with Bug 1323328. Other UA vendors have expressed interest in sharing conformance tests, inspired by WebGL's conformance suite.

>
> -Boris
>
> [1] For example, what does the VRFrameData constructor actually do? The spec doesn't define it at all. Where is the VRPose inside supposed to come from? What values will it contain? I filed https://github.com/w3c/webvr/issues/195 on this, but note that I've spent all of about 5 minutes skimming the spec and ran into this. I have _not_ done a careful read looking for possible interop problems...

VRFrameData is described as receiving the output of the VRDisplay.getFrameData function:

https://w3c.github.io/webvr/archive/prerelease/1.1/#dom-vrdisplay-getframedata

Thanks for all your feedback!

[Boris Zbarsky]

On 3/1/17 5:03 PM, Kip Gilbert wrote:
> We have worked directly with the other WebVR platform implementers to ensure compatibility.

OK, but what is the actual state of that compatibility?

https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and
https://github.com/w3c/webvr/issues/195#issuecomment-283493130 sure
sound like at least Brandon is not on board with those parts of the
current API, and he's one of the spec editors.

> We have regularly scheduled video calls and F2F meetings to improve the spec and remove any ambiguity. We have formed a W3C community working group.

That's good. The question that bothers me is how this interacts with
the ship schedule.

>> [1] For example, what does the VRFrameData constructor actually do? The spec doesn't define it at all. Where is the VRPose inside supposed to come from? What values will it contain? I filed https://github.com/w3c/webvr/issues/195 on this, but note that I've spent all of about 5 minutes skimming the spec and ran into this. I have _not_ done a careful read looking for possible interop problems...
>
> VRFrameData is described as receiving the output of the VRDisplay.getFrameData function:

Yes, but that's totally unrelated to my question about what the
_constructor_ does....

-Boris

[kear...@kearwood.com]

On Wednesday, March 1, 2017 at 2:55:53 PM UTC-8, Boris Zbarsky wrote:
> On 3/1/17 5:03 PM, Kip Gilbert wrote:
> > We have worked directly with the other WebVR platform implementers to ensure compatibility.
>
> OK, but what is the actual state of that compatibility?
>
> https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and
> https://github.com/w3c/webvr/issues/195#issuecomment-283493130 sure
> sound like at least Brandon is not on board with those parts of the
> current API, and he's one of the spec editors.

I tend to agree with Brandon on this particular issue

>
> > We have regularly scheduled video calls and F2F meetings to improve the spec and remove any ambiguity. We have formed a W3C community working group.
>
> That's good. The question that bothers me is how this interacts with
> the ship schedule.
>
> >> [1] For example, what does the VRFrameData constructor actually do? The spec doesn't define it at all. Where is the VRPose inside supposed to come from? What values will it contain? I filed https://github.com/w3c/webvr/issues/195 on this, but note that I've spent all of about 5 minutes skimming the spec and ran into this. I have _not_ done a careful read looking for possible interop problems...
> >
> > VRFrameData is described as receiving the output of the VRDisplay.getFrameData function:
>
> Yes, but that's totally unrelated to my question about what the
> _constructor_ does....

On the spec issue, I am working to make the initial values explicit as you have suggested: https://github.com/w3c/webvr/issues/195

This has not caused any issues with interoperability, as VRFrameData's values are not considered valid until after a call to VRDisplay.getFrameData initializes them and returns true indicating it was successful.

Would this issue block release of WebVR in Firefox 54?

[L. David Baron]

On Wednesday 2017-03-01 12:50 -0800, kgil...@mozilla.com wrote:
> Since the initial implementation, a W3C working group was formed including members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is being conceived.

There seems to be some disagreement within the WebVR community about
whether 1.1 was intended to be shipped in stable releases of
browsers, e.g., in this thread:
https://twitter.com/aeliasnet/status/837139143276711936

What's the intent of the WebVR standards community here?

And is your intend to support the features in 1.1 forever, or to
take them away at some point?

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[kear...@kearwood.com]

On Thursday, March 2, 2017 at 11:04:07 AM UTC-8, David Baron wrote:
> On Wednesday 2017-03-01 12:50 -0800, kgil...@mozilla.com wrote:
> > Since the initial implementation, a W3C working group was formed including members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is being conceived.
>
> There seems to be some disagreement within the WebVR community about
> whether 1.1 was intended to be shipped in stable releases of
> browsers, e.g., in this thread:
> https://twitter.com/aeliasnet/status/837139143276711936
>
> What's the intent of the WebVR standards community here?
>
> And is your intend to support the features in 1.1 forever, or to
> take them away at some point?

Chris's response to that tweet sums this up.

Our first implementation of WebVR 2.0 will be a system add-on exposing the new API, backed by WebVR 1.1. WebVR 1.1 implementations will be around for a long time and have already been shipped by other UA's. It will take some time for 2.0 to be ready to implement as it is still in conception. When the native implementation within Firefox is updated to 2.0, the system add-on will be updated to provide backwards compatibility to the WebVR 1.1 API. At this point, WebVR 1.1 will be deprecated but supported as long as needed. I expect the timeframe to be several years of support for WebVR 1.1 API in production.

The vast majority of sites using WebVR are using one of the WebVR polyfills, such as:

https://github.com/googlevr/webvr-polyfill

This polyfill provides an even higher level abstraction and enables WebVR on platforms without WebVR support, such as phones with a google cardboard holder.

Simply updating this polyfill is all that would be needed for sites that are still on the WebVR 1.1 API once eventually deprecated.

[Boris Zbarsky]

On 3/2/17 1:52 PM, kear...@kearwood.com wrote:
> I tend to agree with Brandon on this particular issue

That's fine. I agree with you and Brandon too. ;) I'm just worried
about possible interop problems more than anything else at the moment.

> Would this issue block release of WebVR in Firefox 54?

To some extent this is a call people more familiar with how this API
gets used and what interop issues can arise should make.

Note that per
https://github.com/w3c/webvr/issues/128#issuecomment-283854007 the
behavior of getFrameData is not interoperable between Edge and Firefox:
we create new objects hanging off the VRFrameData each time, while they
mutate all the existing stuff in-place. This can lead to bugs like code
that tries to optimize by grabbing a reference to one of the typed
arrays and then calling getFrameData and assuming the array they are
referencing is updated (if they test in Edge). Or not updated and
represents the previous frame (if they test in Firefox)...

Again, I only spent a few minutes looking at this spec. What would be
most helpful here is if someone went through it carefully looking for
underpecified bits like this, then filed issues as needed and checked
what browsers actually do in the underspecified cases. Then we can
decide whether whatever behavior differences we find are sufficient that
there is high interop risk from shipping.

-Boris

[Ehsan Akhgari]

Hi Kearwood,

I and a few other engineers have been studying the performance of
Firefox for several weeks now as part of the Quantum Flow project and
one of the serious performance issues that we have been finding in
various parts of the browser have been synchronous IPC messages sent
from the content process to the parent process. We are tracking the
overall issue in bug 1331674, and I had seen WebVR sync IPC messages
come up in our measurements as being particularly bad but unfortunately
I hadn't gotten a chance to file a bug yet because I didn't realize
WebVR is close to being shipped, so sorry for the last minute alarm, but
what is our performance story for WebVR? We have some telemetry probe
that suggest that some of the DOM APIs that we expose can potentially
blow away your entire frame budget. For example,
PVRManager::Msg_GetSensorState (which, as far as I can tell is how we
implement VRDisplay.getFrameData() and VRDisplay.getPose()) is one of
the slowest ones. On Nightly, more than 50% of the calls to this
synchronous IPC take between 8 to 20ms. This means calling one WebVR
API currently can run the risk of blowing away your entire frame budget.
I have filed bug 1344216 for this.

I don't have any VR hardware myself so I have done no profiling myself,
but what is our performance story here? I think the current
implementation strategy of sending synchronous messages to the parent
process isn't going to be viable long term, and honestly it seems to me
that for WebVR specifically it may not even be good enough for a first
implementation. Do you have some Gecko Profiler profiles to share,
ideally from lower end hardware that can run VR demos so that we can get
a sense of what the performance of Gecko on a VR workload looks like?
Has there been though of other implementation strategies?

(FWIW it has recently became quite clear that sync IPC messages can be
*much* worse than sync IO even, we have seen many profiles where sync
IPC messages can easily take *seconds*, so even if they show up as super
fast on a fast machine when the machine isn't under load, they can
essentially take an arbitrary long amount of time in less ideal cases...
I myself have certainly been guilty of adding a fair number of sync IPC
messages before measuring how bad they are in practice.)

Thanks,
Ehsan

On 2017-03-01 3:50 PM, kgil...@mozilla.com wrote:
> As of March 1, 2017 I intend to turn WebVR on by default on Windows. It has been developed behind the dom.vr.enabled preference and has been enabled by default on Firefox Nightly and Dev Edition since November 2015. Other UAs shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel. Microsoft Edge and Google Chrome are also intending to ship. Google Chrome has enabled WebVR on Android with an Origin Trial.

>
> This feature was previously discussed in this "intent to ship" thread, for non-release builds:
>
> https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion
>
> Bug to turn on by default:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368
>
> We will support Oculus and HTC Vive by default. Oculus is already enabled; HTC Vive support with OpenVR has been developed behind the “dom.vr.openvr.enabled” preference and will be turned on with this bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374
>

> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/
>

> Since the initial implementation, a W3C working group was formed including members from Mozilla, Google, Microsoft, Samsung, and Oculus. The API has stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is being conceived.
>

> Windows only support for WebVR would be enabled by default in Firefox 54. OSX is not yet supported by current VR headsets. Beta Linux support for HTC Vive has very recently landed, and will be supported by Firefox after the Firefox 54 uplift.
>
> Cheers,
> Kearwood “Kip” Gilbert
> :kip
>

[Ehsan Akhgari]

On Fri, Mar 3, 2017 at 12:36 PM, <kgil...@mozilla.com> wrote:

> Hi Ehsan!
>
> I believe all IPC messages can be changed to async except GetSensorState
> and SubmitFrame. We cache the results from GetSensorState and re-use it
> until the next frame.
>

Hmm, not sure if I understand correctly. Did you actually mean "except"
there? If we can't guarantee to be able to return the result of
GetSensorState in the same frame as when it was requested in (which is the
case on Nightly right now), caching it for the rest of the frame duration
should be the least of our worries...


> I would like to do some changes to how IPC in WebVR works...
>
> First, I'd like to move the parent side of PVRManager to its own thread or
> possibly a dedicated process. WebVR can be impacted by busy message
> queues. PVRManager is already a top-level protocol and the methods on the
> parent side are self contained in preparation for this.
>

You probably want PBackground for this purpose, although if you're planning
to communicate with the background parent actor synchronously that may not
end up being good enough either. A separate process sounds overkill, and
probably opens the door to solving more problems that you can probably
avoid solving (such as dealing with the additional memory usage of a helper
process.)


> Secondly, we may benefit from using another IPC mechanism for sharing
> per-frame state, which is updating at 90hz and broadcasting the same
> information to multiple children. A fundamental difference with WebVR is
> that children are interested in getting the latest state rather than state
> in a serial fashion. A carefully fenced or double buffered structure (like
> Chromium's gamepad IPC) may provide the low latency, nom-blocking IPC here.
>

Is this something we can use shared memory for? Or would the cost of
locking access to the shared memory undo the benefits?


> For the near-term, I would like to make sure all messages that occur
> outside of WebVR presentation


Sorry, I'm not familiar with all of the terminology here. Which messages
are those, and what parts of WebVR would still use synchronous IPC
communication with your suggestion?


> (ie GetDisplays) are async first, then work on a different IPC mechanism
> and move WebVR's messages into another parent thread / queue.. Would this
> make sense?
>

My first suggestion is to gather some profiles of some WebVR test runs to
get a better sense of what the current situation looks like. Still it
seems to me that we shouldn't have any sync IPC on the path of the DOM APIs
that are exposed to the page.

Cheers,
Ehsan


> Thanks for the feedback!
>
> Cheers,
> - Kip
>
> > On Mar 3, 2017, at 6:47 AM, Ehsan Akhgari <ehsan....@gmail.com>

--
Ehsan

[kear...@kearwood.com]

On Friday, March 3, 2017 at 10:42:43 AM UTC-8, Ehsan Akhgari wrote:
> On Fri, Mar 3, 2017 at 12:36 PM, <kgil...@mozilla.com> wrote:
>
> > Hi Ehsan!
> >
> > I believe all IPC messages can be changed to async except GetSensorState
> > and SubmitFrame. We cache the results from GetSensorState and re-use it
> > until the next frame.
> >
>
> Hmm, not sure if I understand correctly. Did you actually mean "except"
> there? If we can't guarantee to be able to return the result of
> GetSensorState in the same frame as when it was requested in (which is the
> case on Nightly right now), caching it for the rest of the frame duration
> should be the least of our worries...

For GetSensorState, we are not just concerned with the call completing within one frame, but also the timing within a single frame as the value will change depending on the timing of the call. We optimize for late frame pose prediction updates by delaying this call as late as possible within one frame to get the most accurate prediction of the headset's future pose at the end of the frame. As sync messages have other side-effects, this is a candidate to be switched to a different mechanism (such as shared memory).

>
>
> > I would like to do some changes to how IPC in WebVR works...
> >
> > First, I'd like to move the parent side of PVRManager to its own thread or
> > possibly a dedicated process. WebVR can be impacted by busy message
> > queues. PVRManager is already a top-level protocol and the methods on the
> > parent side are self contained in preparation for this.
> >
>
> You probably want PBackground for this purpose, although if you're planning
> to communicate with the background parent actor synchronously that may not
> end up being good enough either. A separate process sounds overkill, and
> probably opens the door to solving more problems that you can probably
> avoid solving (such as dealing with the additional memory usage of a helper
> process.)

The driving need is that the VR messages would not block on any non-webvr messages in the queue.

Ideally we won't need a separate process, but if we do, we would start it only when necessary. The underlying VR API's expect this process to persist for the browser's lifespan and to have mutually-exclusive access to input from the headsets. It seems that the GPU process is the best fit afaict.

>
>
> > Secondly, we may benefit from using another IPC mechanism for sharing
> > per-frame state, which is updating at 90hz and broadcasting the same
> > information to multiple children. A fundamental difference with WebVR is
> > that children are interested in getting the latest state rather than state
> > in a serial fashion. A carefully fenced or double buffered structure (like
> > Chromium's gamepad IPC) may provide the low latency, nom-blocking IPC here.
> >
>
> Is this something we can use shared memory for? Or would the cost of
> locking access to the shared memory undo the benefits?

I would like to explore using shared memory with lockless data structures. Chromium does something similar: https://chromiumconfessions.blogspot.ca/2016/09/chromium-gamepad-api-and-shared-memory.html

>
>
> > For the near-term, I would like to make sure all messages that occur
> > outside of WebVR presentation
>
>
> Sorry, I'm not familiar with all of the terminology here. Which messages
> are those, and what parts of WebVR would still use synchronous IPC
> communication with your suggestion?

GetDisplays is the only IPC that would affect non-webvr sites, and is easy to make asynchronous. It is not timing sensitive and the web-facing api returns a promise.

GetSensorState and SubmitFrame would need to be synchronous, but could be using a different IPC mechanism.

>
>
> > (ie GetDisplays) are async first, then work on a different IPC mechanism
> > and move WebVR's messages into another parent thread / queue.. Would this
> > make sense?
> >
>
> My first suggestion is to gather some profiles of some WebVR test runs to
> get a better sense of what the current situation looks like. Still it
> seems to me that we shouldn't have any sync IPC on the path of the DOM APIs
> that are exposed to the page.

I have done a lot of profiling with hardware assisted latency testing to measure sub-frame timing of the render loop, including the IPC calls. I'd like to automate this with tests and also get telemetry feedback from the wild.

Thanks for all your constructive feedback!

Cheers,
- Kip

[Boris Zbarsky]

On 3/6/17 3:03 PM, kear...@kearwood.com wrote:
> The underlying VR API's expect this process to persist for the browser's lifespan and to have mutually-exclusive access to input from the headsets. It seems that the GPU process is the best fit afaict.

In case it matters, the GPU process does not have "persist for the
browser lifespan" as a goal. In fact, the whole point of the GPU
process is that driver crashes should take down the GPU process but not
the browser. We then restart the GPU process as needed. On some
hardware/software configurations, this is apparently not a rare occurrence.

-Boris

[kear...@kearwood.com]

It would require some work to allow VR to continue after a GPU crash, but perhaps such isolation could be useful eventually and predicate a separate VR process.

[baj...@google.com]

Hi all! I'm a spec editor for WebVR and implementer on Chrome. Wanted to chime in on a few points.

Boris: Thanks for the spec bugs you've filed and the concern about improving the spec language to ensure consistent implementations between browsers. The type of issues you have brought up are exactly the sort of thing that we were hearing from Google's side as well and a large part of why we're pursuing what we refer to as the "2.0" spec (which is a terrible name given that it's intended to ultimately be the only version of the spec, but that's a different matter.)

The 2.0 version of the spec currently exists mostly in explainer form right now (https://github.com/w3c/webvr/blob/master/explainer.md) while we prep for a TAG review. Once that's complete and we've made the appropriate adjustments we'll start working on real spec language. It's my intent to focus on making that version of the spec far more explicit, algorithmic, and attentive to web platform conventions. (I've been frequently referring to https://garykac.github.io/procspec/ and https://w3ctag.github.io/design-principles/ when figuring out what the spec language should look like.)

Given that we know that we have a newer/better version of the spec in the pipeline We've been reluctant to personally put much time into fleshing out the 1.1 version. I don't think I'd classify 1.1 as "stabilized" so much as "no longer being invested in". I wouldn't object to updating it with clarifications if necessary, though.

I should also point out that on Google's end we are currently making the 1.1 spec available via an Origin Trial, but have no plans on enabling it by default at this time. It's our intent to continue the Origin Trial while the 2.0 spec is finalized, stripping out some deprecated functionality in the meantime to prevent developers from growing dependent on it. Once 2.0 is ready we'll replace our 1.1 implementation entirely, run the Origin Trial for a little longer to gather feedback, and then enable by default.

A few other points of clarification, mostly referring to Kip's original post:
- We currently have a W3C community group, rather than a full fledged working group.
- Oculus has been participating in development of the spec but (somewhat to my surprise) is not yet an official member of the community group.
- Samsung is currently shipping an even older version of the API (what we call 1.0). They are working on 1.1 support now, as I understand it.

[Kearwood "Kip" Gilbert]

We believe that we have addressed the remaining issues and we will turn WebVR on by default in Windows, shipping in Firefox 55.

After discussions with the other major browser vendors, we believe that we are all on track to ship a compatible version of the WebVR 1.1 draft specification and have addressed the issues brought up in this thread.

Additionally, Microsoft announced yesterday that their implementation (with whom we share Web Platform Tests) has just shipped with the Creators' Update:
https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/ <https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/>

We and other browser engines have expressed an intent to either support 1.1 via a polyfill of 2.0 or a side by side implementation, depending on what is easier from their engine. If there is very little uptake or we are able to transition users to 2.0, then we may be able to deprecate 1.1 entirely. We plan to have the discussion around that process in the group later next year, around the time when we expect 2.0 to be finalized.

Thanks everyone, within and beyond the MozVR team, for making this possible!

Cheers,

- Kearwood “Kip” Gilbert

> On Mar 1, 2017, at 12:50 PM, kgil...@mozilla.com wrote:
>
> As of March 1, 2017 I intend to turn WebVR on by default on Windows. It has been developed behind the dom.vr.enabled preference and has been enabled by default on Firefox Nightly and Dev Edition since November 2015. Other UAs shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel. Microsoft Edge and Google Chrome are also intending to ship. Google Chrome has enabled WebVR on Android with an Origin Trial.
>
> This feature was previously discussed in this "intent to ship" thread, for non-release builds:
>

> https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion <https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion>

>
> Bug to turn on by default:
>

> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368 <https://bugzilla.mozilla.org/show_bug.cgi?id=1343368>

>
> We will support Oculus and HTC Vive by default. Oculus is already enabled; HTC Vive support with OpenVR has been developed behind the “dom.vr.openvr.enabled” preference and will be turned on with this bug:
>

> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374 <https://bugzilla.mozilla.org/show_bug.cgi?id=1343374>
>
> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/ <https://w3c.github.io/webvr/archive/prerelease/1.1/>