DragRotateHandler in a deadlock on mobile

[remster]

v0.32.1:

Steps to Trigger Behavior

1. Open jsfiddle (on Chrome 56.0.2924.87)
2. This only reproduces itself on a mobile browser, so launch the dev tools (Ctrl-Shift-i or right-click->Inspect)
3. Pick a mobile device (I use Nexus 5):
   
4. Long-click on the map until it becomes unresponsive - i typically need to do this twice.

Expected Behavior

map panable

Actual Behavior

map not panable

What i observe in the debugger is that on a short-click the DragRotateHandler._ignoreEvent (called in response to slightly delayed 'mousedown') returns true, whilst on the long click it returns false. In the process, the DragRotateHandler becomes armed and seemingly subscribes itself to 'mousemove' and 'mouseup'.. yet somehow 'mouseup' never reaches it so it hijacks the whole ui.

[kristfal]

On certain devices, a long touch tap is handled as a right click along with a regular tap fired a few ms between each other, leading to the dragRotate gridlock.

The current best workaround is to disable the dragRotate handler when you know that you are running on a mobile device.

[remster]

Thanks @kristfal - that's the workaround i figured myself. It's still a bug i hope you agree - and i filed it under this assumption.

[kristfal]

@remster Yes, I agree it is a bug. Interaction handlers on touch haven't seen much love lately with quite a few open issues: #1928, #2784, #2784, #3094 and #2204 which might fix this issue.

Additionally, there is a few interaction handler diffs between gl-native and gl-js that haven't been added as issues. On top of my mind: lack of two-finger drag to pitch, lack of double-tap drag-zoom, lack of inertia for rotate gestures and generally less inertia in js than native.

Most of these issues are easy to fix, but touch can be tricky to do properly cross-browser and require a bit of hardware to test, so that is probably why they are lingering.

A while back ago, the core team discussed a complete re-write (see discussion in #2419). I don't know if that rewrite is still discussed (it's not really that much code written anyway), or if they are open to PRs to fix those issues. If they are, I'd be happy to work on some PRs when I have time.

[mourner]

@kristfal we would very much welcome any improvement PRs for this — sorry for not spending enough time on the touch interactions code. We have infinite things to improve and very limited bandwidth.

[kristfal]

@mourner you guys are doing 🥇 work here with gl-js, no criticism 😄

gl-js is getting fast enough to rival gl-native on the most used mobile devices now. We're all in on using it as a mobile framework, and have done quite a few internal forks and quick hacks to get around the most common issues.

Moving forward, I don't mind spending a bit more time cleaning up those changes and issue a few pull requests when I have some free time. Would you rather have one pull request fixing several issues or individual PRs for each issue?

I'll look into the new features after the existing issues are mostly resolved.

[mourner]

Thanks a lot Kristian!

Would you rather have one pull request fixing several issues or individual PRs for each issue?

Definitely individual PRs and breaking bigger PRs into smaller ones as much as possible. Makes it much easier to review.

[jfirebaugh]

Is this still reproducible? I'm not able to see the behavior described using the JSFiddle and the steps outlined in the OP.