Falling back in Chrome 53.0.2785.116 m
Neither the demo page, or my own (otherwise working) instance seems to work in Google Chrome, at least Version 53.0.2785.116 m.
No obvious errors in the developer console either.
I can't seem to reproduce your issue. Tested on Chrome 53.0.2785.116 (64-bit) and Chrome Canary 55.0.2865.0 (64-bit), both are working without a hitch.
What do you mean by "not working"?
I see what you're seeing on one computer, but on the one I happened to be on at the time I'm still seeing it not working. And by that, I mean I'm getting class="paver--fallback" and not of the panning functionality.
I'm sorry, but without any further information it is next to impossible to debug. How does the markup in the non-functional version look like? Is the markup being replaced, or is it not?
The markup is being replaced, and is in the fallback state. I'll reinstall this Google Chrome, and try on other machine to attempt to replicate the failure. If I can, I'll refile the bug.
Dell Inspiron 5558 (notebook, touch support with 10 touch points) Windows 10 Home 64-bit Google Chrome 53.0.2785.116 m Mozilla Firefox 48.0.2
On this machine Firefox functions fully with Paver. On Google Chrome however, it enters fallback mode.
With setup and Google Chrome, document.createEvent('TouchEvent') executes successfully. So global.features.isTouch = true while global.features.hasGyroscope == false. Resulting in a call to this.fallback().
Just to test out, forcing global.features.isTouch = false seems to let things work as expected in Google Chrome, though that's obviously not a fix.
That is quite peculiar. I am unable to reproduce your issue on Chrome, but that's on OS X. I'll see if I can grab a Windows machine to try it on.
I'd like to highlight, just in case, that my particular machine is touchscreen laptop.
If that's the case, sounds like something is off with the determination of the device supports touch events. I'll try to see if that's something that I can debug and fix. The code for determining if the device is "touch" or not is rather a misnomer itself, as it does the following:
- Checks if the device supplies gyroscopic data and,
- Checks if tilting is enabled in the initialisation settings
So it seems like the touchscreen laptop is satisfying both conditions, but for some reason does not supply the correct gyroscopic data. That should've been caught by a fail-safe check performed for point no. 1, but it seems to be failing in your case.
For now try manually forcing isTouch, but I do acknowledge it's only a workaround and not a true fix.
Let me know anything I can do to assist.