Hammer.js: Panstart not fired on image since 2.0.5

[redaxmedia]

Hello,

I found and issue that was introduced in version 2.0.5. The past months I'm working on a Pageflip project that does have a zoom and drag feature for brochures.

2.0.4:
Everything is working as it should be, the panstart gets fired on div containers and images. Dragging the image around works like a charm.

2.0.5:
The panstart gets fired correctly on div containers, but on images the mouse pointer turns into drag image state and the panstart events gets fired after I released the mouse. Therefore it does not trigger the drag feature.

Tested in Firefox 43, but seem to work in Chrome 47.

The brochure image does have the attribute draggable="false" and pageflip div container was styled with user-select: none;. None of these factors were touched during the recordings.

[runspired]

@redaxmedia could you use 2.0.6? This is 2.0.5 and there was a bugfix in between.

It also appears you are saying this works in Chrome but not Firefox from your comments, we made an alteration to vendor prefixes after 2.0.4 for moz that appears to be the wrong capitalization, it's possible we missed something.

[runspired]

@redaxmedia another thought here, is there only a single Hammer instance or multiple hammer instances in play? The big fixed between 2.0.4 and 2.0.6 were to address configuration leaks between Recognizers and Managers, previously the last one created of each would become the rules that were applied to all instances of them. You may have been unwittingly dependent on that bug.

[redaxmedia]

There is just one hammer instance. I tried 2.0.6 too with the same results.

Maby you can point me to the invalid prefixes and I can mod hammer.js to see what happens.

[runspired]

@redaxmedia https://github.com/hammerjs/hammer.js/commit/3ea47f3aebadc9d3bb6bf52bc8402cad135ef8a9

[runspired]

Their prefixes are -moz- for CSS

And Moz for JS

But it's possible (see second link) that's not actually 100% accurate for what we are doing, some code prefixes are in fact moz. (confusing as hell, I know).

[redaxmedia]

I made a diff on the hammer.js file and played around a bit. The vendor prefixes are fine, the issue seems to be caused by the following code block:

//https://github.com/hammerjs/hammer.js/blob/master/hammer.js#L1230-L1240
if (hasNone) {
    //do not prevent defaults if this is a tap gesture
    var isTapPointer = input.pointers.length === 1;
    var isTapMovement = input.distance < 2;
    var isTapTouchTime = input.deltaTime < 250;
    if (isTapPointer && isTapMovement && isTapTouchTime) {
        return;
    }
}

Debug on Firefox, I guess this means that a Tab instead of a Pan was detected:

isTapPointer: true
isTapMovement: true
isTapTouchTime: true

Uncomment the if statement and the panstart get fired again in Firefox.
Does this help?

[runspired]

@arschmitz if you could confirm but I think what we are seeing is that the old tap default settings were actually hard coded into hammer for preventDefault purposes and need to pull from the config.

[arschmitz]

@runspired yup i think you have it exactly

[runspired]

@redaxmedia where did you get on this?

[redaxmedia]

@runspired What concerns your question?

[emersonyu]

Any workarounds for this? I'm seeing similar behavior in 2.0.6, on images, or block level anchor tags. Also, the example at http://hammerjs.github.io/ doesn't work too well with panning either. When I let go of the mouse, the square keeps moving until i click again. This is in FF 44.0.2 (mac).

[st11x]

I am experiencing the same on Chrome, Safari, and Firefox on the Mac and have been able to reproduce it here

https://jsfiddle.net/9ufvvgds/6/

If you clicked and dragged the Google image, you only get one Pan message.

However, if you did the same with "Some Text", you will see the Pan messages continuously.

The Pan example on http://hammerjs.github.io/ works because it included the touch emulator, so that is one workaround.

[erikwilson]

Am seeing this issue with images inside of a svg element contained within a div, for Firefox only with most recent versions of Hammer.JS.
Our resolution was to make sure the parent div is not draggable and has an onmouse="return false" or similar event handler to prevent default behavior.

[nateabele]

Experiencing the same thing on Chrome 52.

[runspired]

@nateabele @erikwilson @emersonyu @st11x

RE https://jsfiddle.net/9ufvvgds/6/

This is fixed very simply in that example by the following:

var x = new Hammer($('#foo')[0]);
$('#foo').find('img').on('mousedown', function(e) {
  e.preventDefault();
});
x.on('pan', function(e) {
  $('#bar').text('Pan ' + $('#bar').text());
});

This is not a behavior that Hammer will "correct" because it would be incorrect to do so. If you do not want users to be able to drag images, or want to control their dragging, you should call preventDefault on the image.

However, in the case in which hammer is attached directly to the element, we should preventDefault, and we do, as is evidenced by changing that fiddle to the following:

var x = new Hammer($('#foo').find('img')[0]);
x.on('pan', function(e) {
  $('#bar').text('Pan ' + $('#bar').text());
});

This issue above in this thread is specific to Firefox, which appears to be avoiding the preventDefault from taking effect.

[nateabele]

@runspired Noted, thanks. Want a PR against https://github.com/hammerjs/hammerjs.github.io/blob/master/tips.md to document that behavior?

[runspired]

@nateabele that would be welcome :)

[redaxmedia]

Hello,

I'm fine with the opinion that Hammer.js should not change the browser's default behavior. The only drawback is, that countless people are going to run into this issue.

However, this is a question of philosophy...

[peterpeterparker]

Two years later, same behavior observed in Safari. I followed the workaround of @runspired aka

<img (dragstart)="preventDrag($event)">

preventDrag($event) {
   $event.preventDefault();
}