Rotation appears to rely on non-standard Touchlist ordering consistency

[RByers]

The TouchEvents spec says nothing about the order of touches in a TouchList. But when computing the 'rotation' angle it appears that hammer always computes the angle between touches[0] and touches[1]. If the touches happen to be in different positions in the array from event to event, this will result in 180 degree flipping back and forth. We saw an example of this in Chrome and although we're planning in fixing that case, it's possible there are others (eg. depending on the OS behavior, and possibly behavior in other browsers). I raised this as an issue in the TouchEvents spec but it sounds like we're unlikely to have the spec require touch points to have a consistent order in the list.

[RByers]

BTW, I say "appears" because I haven't explicitly tested this in current hammer.js builds. We saw the issue on this site, and looking at the current hammer.js code it still appears to me to be dependent on the TouchList ordering.

[RByers]

A simple solution to this would probably be to sort the two points by their 'id' (effectively making rotation be the angle between the lower ID touch and the higher ID touch).

[arschmitz]

@RByers Thanks for reporting this things have been slow on this project for a while but we are ramping back up and will be sure to look at this and try and get it fixed!

[RByers]

Great, thanks!

[runspired]

Closing in favor of #610 and PR #696

[arschmitz]

Looking back at this it is still an issue

[crabmusket]

I think I fixed it ^