Pose not working on in Android WebView using Chrome 62+

[meatwallace]

• WebVR polyfill doesn't provide device movement tracking in an Android WebView using
  • Chrome Stable/Beta/Dev/Canary 62.0.3202.66+
  • Android System Webview version 62.0.3202.66+
• Working as expected using Chrome Stable 61.0.3163.98
• Adding an event listener for 'devicemotion' returns an initial event object but no subsequent events as expected.
• Issue discovered can be easily replicated by visiting any site using the WebVR polyfill in the aforementioned WebView versions, ex. samples on https://aframe.io

[jsantell]

Thanks for filing!

For the record, many of the examples on aframe.io use older versions of aframe and the polyfill.

[meatwallace]

@jsantell - tested this exhaustively and it appears to be an issue with the DeviceMotion API in Chrome 62+. We ran into this problem on a project, and have tested across a wide range of Chrome/Android System Webview versions. The A-Frame samples are just an easy way to visually reproduce the issue, although a simple window.addEventListener('devicemotion', console.log, true) will expose it too. Not sure if this issue is relevant to the WebVR polyfill necessarily - sorry. Have opened an issue on the Chromium bug tracker.

Thanks

[jsantell]

Thanks for digging into this, @meatwallace -- definitely something we'll need to handle for the polyfill. I'll keep an eye on the Chromium issue. Thanks for putting this on the radar!

[meatwallace]

No worries. Although the issue is with Chromium, if there's anything you think we should test to accelerate resolving the issue, would love to hear.

The release of Chrome 62 happened the day before our scheduled product launch, so we're heavily invested in resolving or finding a workaround for the issue. We've tried:

• Passing sensor data into the WebView and generating synthetic DeviceMotion events. As expected, it suffers from performance and latency issues, rendering it unusable.
• Using Origin Trials to enable experimental features. It turns out this is unavailable in a WebView, so we can't use the native WebVR API, and we can't write a new pose sensor with the Generic Sensor API.

One of our engineers is working on using a CrossWalk WebView. Seems like the easiest way to bundle a locked version of Chrome. As it's not maintained, this isn't a desirable solution. When complete, I'll share the results, although as it's using Chrome 53, I think we'll run into perf issues.

Beyond that, we're investigating bundling Chrome itself with our app so that we can lock the version, but haven't found any clear strategy for doing so, and our skillset isn't suited for the task.

If anyone has knowledge about bundling Chrome, or any alternative avenues to explore, please shout out! I don't know how widespread this use case is - I imagine it's niche, but if it's affecting anyone else, we would love to collaborate to resolve it.

Sorry if I've gone too far out of scope of the polyfill. As we could be waiting for a patch in Chrome for a while, I figure this is a good place to discuss workarounds in the interim.

Cheers

[bri-bri]

I just verified the Chrome fix that was merged and released in the Canary build: https://bugs.chromium.org/p/chromium/issues/detail?id=779443

If you have an Android 8 device, you can preview the fixed version by downloading Chrome Canary from the play store, then changing your WebView implementation in developer settings.

[jsantell]

Looks like this is fixed in m63+, and with m62 out currently, not sure what a possible workaround is unfortunately 😕 let's leave this issue open if there are any immediate short term fixes we can do on our end

[meatwallace]

Whilst not an optimal solution at all, we've bundled the last release of the Crosswalk WebView (uses Chrome 53) with our app and are conditionally using it if we detect Chrome / Android System WebView 62.x on the device. Minor performance regressions and it tacks ~40mb onto our bundle, but it works.

[jsantell]

Fixed in Chrome 63+, looking into solutions that can prevent this sort of breakage on Chrome's end; closing for now, thank you for reporting and following through on this issue @meatwallace!