upgrade version of webvr-polyfill dependency

[cvan]

I'm filing this to separate the issue of upgrading webvr-polyfill from fixing the source-map JS error raised in issue #54.

---

From Slack:

caseyyee [10:48 PM]
@cvan ok, looks like with the polyfill, all the desktop mouse stuff was removed and they just use orbit controls on desktop. it doesn’t even return any polyfilled vrdisplays
so it's basically strictly for mobile only

cvan [10:06 PM]
the new one has updates for the Sensor API
cvan [10:06 PM]
devicemotion is being deprecated
cvan [10:06 PM]
and it fixes a few 1.1 compliance issues

caseyyee [10:54 PM]
Yeah, that was my thought. Provide some kind of sensible desktop usage. maybe some FPS controls.
is there any major reason to use the new polyfill? I can update the polyfill and add back some default controls as a update.
so do that after we push to the asset store.

[delapuente]

Unity is different from creating experiences with the web. I guess people is used to not move if there are no behaviours in the camera. I filed another different bug to provide a set of FPS controls to navigate the scene but I would not directly attach any behaviour to the camera set.

[caseyyee]

@delapuente I think having a good default behaviour would be pretty huge for anyone just wanting a simple control scheme for looking and moving around.

I would actually make this as part of a separate component that could be easily added. Maybe even as part of the default prefab so that it's 0 effort for anyone just wanting to drop in a model, build and share.

[cvan]

relevant for posterity's sake: see PR that was closed because of aforementioned issues (and see discussion in PR) #110

[jsantell]

Just an FYI, see immersive-web/webvr-polyfill#307

tldr: Chrome m65 may have a breaking change for deviceorientation events, possibly with a fix that lowers frequency of events and may have a rotationRate unit change (m66 will definitely have this change, requiring an updated polyfill). Just a heads up we'll need to release a new version of the polyfill with these changes, and something that should probably be updated here and A-Frame. I'll keep ya'll updated, and thanks to @dustinkerstein for finding and reporting this!

[jsantell]

Looks like rotationRate is being uplifted to m65, requiring a new release for next week.

Confirmed that the rotationRate change is in m66, not m65.

[dustinkerstein]

@jsantell where did you find that they are moving it into m65? That's going to break WebVR for most people (those that depend on Polyfill which is likely the vast majority).

[jsantell]

@dustinkerstein that was my interpretation of https://bugs.chromium.org/p/chromium/issues/detail?id=805146#c23, although asked for confirmation to make sure I understand

[dustinkerstein]

My interpretation was that the rotationRate change is targeted only for m66 and is tracked here but we should definitely clarify that.

The other issue with deviceOrientation (not deviceMotion as I originally thought) will be released in m65 unless they revert the fix in the next couple days. I believe this is going to break deviceOrientation for a very large percentage of devices, though it doesn't impact WebVR since the Polyfill only uses deviceMotion.

[jsantell]

Confirmed with Reilly that the rotationRate change is in m66, not m65, tracking immersive-web/webvr-polyfill#307

[jsantell]

Note that the 0.10.3 release is out with the Chrome m65-67 fixes as well as the fix for immersive-web/webvr-polyfill#308

[cvan]

@delapuente given #125, let us know if you have the bandwidth to work on this. if not, we'll get it done in the next milestone between @caseyyee and myself. thanks!