Panstart event not recognized after .stop()

[mvaivre]

Hey,

It seems that whenever I stop to recognize events in the current input session, the next panstart is "skipped".
Am I doing something wrong? I am trying to avoid panning if the origin of the pan is not at the edge of the screen. I use Hammer v 2.0.4.

hammer = new Hammer(document.documentElement)

hammer
      .on('panstart', (e) ->
        if e.center.x < 50
          panstart(e)
        else
          hammer.stop()
      )
      .on('panmove', (e) ->
        e.srcEvent.stopPropagation()
        panmove(e)
      )
      .on('panend', panend)

[runspired]

Duplicated this bug: http://codepen.io/anon/pen/pJdBJB

The session should be cleared on the next input start, but is apparently not: https://github.com/hammerjs/hammer.js/blob/master/hammer.js#L443-L451

It seems likely the previous input session is still considered active following .stop(), even when forcibly stopped with .stop(true).

using FORCE_STOP did not let the next INPUT_START begin a new session either.

The session + recognizer logic is here: https://github.com/hammerjs/hammer.js/blob/master/src/manager.js#L71-L119

[glomotion]

So i've just now discovered this bug myself - I know it's often hard to predict with these sorts of things - though was wondering if i might trouble you guys for an eta of a potential fix to this issue? We're using hammer for quite alot of touch based web experiments, and this bug is causing some quite annoying interactivity glitches... :P

[runspired]

Early September is currently the target for the first patch release post maintainer changes. Anything with will-patch will be targeted for that. We had a lot of issue triage and roadmap considerations to go through to determine out path forward (We're trying to collaborate with other projects to ensure the state of gesture support across all projects improves a lot this year :) ).

[runspired]

Does Merging #824 potentially fix this too?

[jabyrd3]

Any update on this? I'm on 2.0.4 and still seeing the issue.

[runspired]

This may have been a pointers.length related bug.

[junnny]

I add the css style 'backface-visibility: hidden;' to the el, and this fix the issue for me.

[junnny]

^ @runspired