double tap and long press

[javismiles]

Good day,
with the code below,
the doubleTap fires correctly using the mouse, but using the finger on the screen of my HP Spectre 13 laptop, the doubleTap fires on a single tap, instead of on a double tap.
And the superpress event doesnt fire at all neither with mouse or touch, any tips?

    var el = document.querySelector("#outermain");
var mc = new Hammer.Manager(el);
mc.add(new Hammer.Tap({ event: 'doubletap', taps: 2 }));
mc.add(new Hammer.Press({ event: 'superpress', time:500 }));

mc.on("doubletap", onDoubleTap);
mc.on("superpress", onPress);

function onDoubleTap(ev) {console.log("double tap");}
function onPress(ev) {console.log("press");}

[javismiles]

even on this page
http://codepen.io/jtangelder/pen/pBuIw
clicking once on the screen of my HP touch enabled spectre 13 laptop fires the double tap instead of the single tap

[javismiles]

so double tap may be broken on touch-enabled laptop screens (at least in mine), and also the press event just doesn't fire at all for me

[javismiles]

This is taken from your own examples (i just added the press event lines),
and again, one single tap on my screen fires the Doubletap event. And also the Press handle is never ever fired.

var el, hammer;

var tripleTapCount = 0,
doubleTapCount = 0,
tapCount = 0;

    var el = document.querySelector("#outermain");
    hammer = new Hammer(el, {recognizers: []});

    var tap = new Hammer.Tap();
    var doubleTap = new Hammer.Tap({event: 'doubleTap', taps: 2 });
    var tripleTap = new Hammer.Tap({event: 'tripleTap', taps: 3 });
    var press = new Hammer.Press({event: 'press'});

    hammer.add([tripleTap, doubleTap, tap]);
    hammer.add([press]);

    tripleTap.recognizeWith([doubleTap, tap]);
    doubleTap.recognizeWith(tap);

    doubleTap.requireFailure(tripleTap);
    tap.requireFailure([tripleTap, doubleTap]);

    tripleTapCount = 0;
    doubleTapCount = 0;
    tapCount = 0;

    hammer.on('press', function() {
        console.log("PRESSS DOWN");
    });

    hammer.on('tap', function() {
        tapCount++;
        console.log("tapcount:"+tapCount);
    });
    hammer.on('doubleTap', function() {
        doubleTapCount++;
        console.log("doubleTapCount:"+doubleTapCount);
    });
    hammer.on('tripleTap', function() {
        tripleTapCount++;
        console.log("tripleTapCount:"+tripleTapCount);
    });

[PixelsCommander]

@runspired This is not a device specific bug. You can easily reproduce in Dev Tools mobile mode with preset "Laptop with touch". Basically you would have this bug on any laptop with touch screen and they are not rare things nowadays.

[runspired]

@PixelsCommander that's the definition of device specific. It appears that both the mouse input and the touch input are utilized. It also depends on whether such a device fire both mouse and touch events when the screen is touched or just touch events. This bug is very likely due to some of those platforms incorrectly firing both.

@arschmitz thoughts on restricting input recognizers by input type? e.g. if you start with a recognizer session with mouse input, touch input will be ignored?

[runspired]

Related Issues:

• better mouse vs. touch detection Remove navigator.userAgent #812

[arschmitz]

Yes recognizers should only use a single input type within the same gesture.

[runspired]

Theoretically this is already the case

https://github.com/hammerjs/hammer.js/blob/master/src/input/touchmouse.js#L25-L35

[runspired]

@arschmitz the issue actually isn't "within the same gesture", each "tap" is it's own gesture, I suspect we're going through a complete recognizer lifecycle for both the mouse and the touch version of the events. We need to have the manager stop recognizing either touch or mouse entirely depending on which is received first until the end of that gesture's life cycle.

[arschmitz]

@runspired thats what i meant sorry iv debated this same issue on other projects. and have always maintained they trying to support simultaneous inputs of different types is to much of an edge case and too crazy to support.

I dont think iv ever seen someone try to use the touch screen with one hand and mouse with the other at the same time. And even if they do we should just not support this too many bugs and edge cases like this one to even think about it in my oppinion

[PixelsCommander]

@arschmitz Our users already found that and we are still in closed beta.

[arschmitz]

@PixelsCommander you found your users using the touch screen and the mouse at the same time? my understanding here is this is the mouse event which is generated by the touch event not independant events?

[PixelsCommander]

They just have laptops with touch and mouse. I know very little on how hammer is built under the hood but having touch and mouse events in browser brakes double tap which seems to be reflected in this issue.

[arschmitz]

@PixelsCommander yes no one is saying there is not an issue currently we are simply talking about how to fix it

[PixelsCommander]

@arschmitz Sorry Alexander, misunderstood.

[BillBooks]

The double tap problem is that on a touch enabled device, Chrome delivers these events (plus a few others) for a touch tap: touchstart touchend mousedown mouseend click in that order The code in TouchMouseInput to set allow to false during the touch assumes that it's sufficient for allow to be false while the touch is active, but this sequence breaks that. As far as I have been able to determine, the only way to stop Chrome from delivering the mouse events is to call preventDefault for one of the touch events, but that also suppresses the click event.

Calling preventDefault in your tap handler won't work because by the time it fires, the real touchend event handler is off the stack because of the requireFailure.

Some experimenting with https://jsfiddle.net/BillAtYuzu/xoznn4yp/3/ suggests that Chrome will send the mouse start event eventually (300 ms perhaps?) if you press and hold, and that it doesn't send the mouse events at all if the touch moves (i.e. for drags).

Don't know why the press handler is failing even for mouse presses. I have not seen that misbehavior in my testing