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.

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

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

Open
RByers opened this Issue May 12, 2015 · 7 comments

Comments

Projects
None yet
4 participants
@RByers

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

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers 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 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

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers 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).

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

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Jun 7, 2015

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!

Contributor

arschmitz commented Jun 7, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jun 8, 2015

Great, thanks!

RByers commented Jun 8, 2015

Great, thanks!

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

@runspired

This comment has been minimized.

Show comment
Hide comment
@runspired

runspired Aug 7, 2015

Contributor

Closing in favor of #610 and PR #696

Contributor

runspired commented Aug 7, 2015

Closing in favor of #610 and PR #696

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Aug 3, 2016

Contributor

Looking back at this it is still an issue

Contributor

arschmitz commented Aug 3, 2016

Looking back at this it is still an issue

crabmusket added a commit to crabmusket/hammer.js that referenced this issue Sep 12, 2017

Calculate rotation correctly when pointers change order
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 referenced a pull request that will close this issue Sep 12, 2017

Open

Calculate rotation correctly when pointers change order #1136

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Sep 12, 2017

I think I fixed it ^

crabmusket commented Sep 12, 2017

I think I fixed it ^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment