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

double tap and long press #863

Closed
javismiles opened this Issue Oct 29, 2015 · 16 comments

Comments

Projects
None yet
5 participants
@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

This comment has been minimized.

Show comment
Hide comment
@javismiles

javismiles Oct 29, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@javismiles

javismiles Oct 29, 2015

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

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 comment has been minimized.

Show comment
Hide comment
@javismiles

javismiles Oct 29, 2015

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);
    });

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

This comment has been minimized.

Show comment
Hide comment
@PixelsCommander

PixelsCommander Jan 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@runspired

runspired Jan 5, 2016

Contributor

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

Contributor

runspired commented Jan 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@runspired

runspired Jan 5, 2016

Contributor

Related Issues:

  • better mouse vs. touch detection #812
Contributor

runspired commented Jan 5, 2016

Related Issues:

  • better mouse vs. touch detection #812

@runspired runspired added this to the 2.1.x milestone Jan 5, 2016

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Jan 5, 2016

Contributor

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

Contributor

arschmitz commented Jan 5, 2016

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

@runspired

This comment has been minimized.

Show comment
Hide comment
@runspired

This comment has been minimized.

Show comment
Hide comment
@runspired

runspired Jan 5, 2016

Contributor

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

Contributor

runspired commented Jan 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Jan 5, 2016

Contributor

@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

Contributor

arschmitz commented Jan 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@PixelsCommander

PixelsCommander Jan 5, 2016

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

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

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Jan 5, 2016

Contributor

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

Contributor

arschmitz commented Jan 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@PixelsCommander

PixelsCommander Jan 5, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Jan 5, 2016

Contributor

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

Contributor

arschmitz commented Jan 5, 2016

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

@PixelsCommander

This comment has been minimized.

Show comment
Hide comment
@PixelsCommander

PixelsCommander Jan 6, 2016

@arschmitz Sorry Alexander, misunderstood.

@arschmitz Sorry Alexander, misunderstood.

@BillBooks

This comment has been minimized.

Show comment
Hide comment
@BillBooks

BillBooks Feb 23, 2016

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

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

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