Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rotation appears to rely on non-standard Touchlist ordering consistency #791

Open
RByers opened this issue May 12, 2015 · 7 comments · Fixed by xlf1024/hammer.js#1 · May be fixed by #1136
Open

Rotation appears to rely on non-standard Touchlist ordering consistency #791

RByers opened this issue May 12, 2015 · 7 comments · Fixed by xlf1024/hammer.js#1 · May be fixed by #1136
Labels
bug

Comments

@RByers
Copy link

RByers commented May 12, 2015

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 RByers mentioned this issue May 12, 2015
Open
@RByers
Copy link
Author

RByers commented May 12, 2015

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
Copy link
Author

RByers commented May 12, 2015

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
Copy link
Contributor

@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!

@arschmitz arschmitz added the bug label Jun 7, 2015
@RByers
Copy link
Author

RByers commented Jun 8, 2015

Great, thanks!

@RByers RByers changed the title Rotation applies to rely on non-standard Touchlist ordering consistency Rotation appears to rely on non-standard Touchlist ordering consistency Jun 8, 2015
@runspired
Copy link
Contributor

Closing in favor of #610 and PR #696

arschmitz pushed a commit that referenced this issue Aug 8, 2015
@grma1 @arschmitz
Rotation: Do not depend on non standard touch list ordering
287720a 
Fixes #610
Fixes #791
Closes #696
@runspired runspired mentioned this issue Nov 12, 2015
Closed
@arschmitz arschmitz reopened this Aug 3, 2016
@arschmitz
Copy link
Contributor

Looking back at this it is still an issue

@arschmitz arschmitz mentioned this issue Aug 3, 2016
Open
crabmusket added a commit to crabmusket/hammer.js that referenced this issue Sep 12, 2017
@crabmusket
Calculate rotation correctly when pointers change order
cec7d32 
Fix hammerjs#791 by always calculating rotation by considering pointers in order of their identifier. This catches edge cases where pointers change order in the array during a gesture.
@crabmusket crabmusket linked a pull request Sep 12, 2017 that will close this issue
Open
@crabmusket
Copy link

crabmusket commented Sep 12, 2017 •
edited

I think I fixed it ^

@xlf1024 xlf1024 mentioned this issue May 5, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
4 participants
@arschmitz @runspired @crabmusket @RByers