Skip to content

Mouse events do not participate in gestures on touch-enabled devices #471

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

Closed
wants to merge 1 commit into from
Closed

Conversation

grayrest
Copy link

Some devices (like Windows 8 PCs) are touch enabled... but they also have a mouse! The result of only listening to touch events when feature detecting is that drag and drop for these devices seems broken using mouse.

The patch seems to correct the issue and not break anything. The PR is mostly to make you aware of the issue.

@tilomitra
Copy link
Contributor

Thanks for this pull request! This is something that I am looking into currently. I'll report my findings back here.

@ghost ghost assigned tilomitra Feb 27, 2013
@tilomitra
Copy link
Contributor

Hey, this fix actually won't help under the hood because these arrays aren't iterated on by any module AFAIK. I'm going to go ahead and close this, but you can follow this ticket for progress:

http://yuilibrary.com/projects/yui3/ticket/2533158

@tilomitra tilomitra closed this Mar 14, 2013
@grayrest
Copy link
Author

We're using this in production at Squarespace and support has confirmed the fix with customers. The YUI .on methods can take an array as the first argument to register the function as the handler for all events in the array. There's no other iteration happening.

@tilomitra tilomitra reopened this Apr 5, 2013
@tilomitra
Copy link
Contributor

@grayrest You're right re. the .on() method accepting the array, so that works. I think this is a good start, but the individual modules (event-tap, event-gestures) still need a way to prevent the second listener from firing the callback in a touch environment.

For example, if you're on a device that uses both mouse and touch input, and you touchstart on a node, the mousedown that is triggered should not fire the callback again.

Does that make sense? Did you guys tackle that issue at Squarespace by any chance?

@grayrest
Copy link
Author

grayrest commented Apr 5, 2013

The only fix I've put in place is the one included here. A lot of interactions in our system are event-gesture by way of DD and this patch doesn't seem to trigger taps there. I also haven't received any bug reports about spurious taps but most taps in our system are idempotent. I just checked a few that aren't and we're double triggering from what looks like the 300ms fallback click trigger. Haven't attempted a fix.

@doulostheou
Copy link

I'm not sure if I have anything to add to this or not, but I thought I would comment on my experience using Windows 8 and the dd-plugin module. Using Internet Explorer 10.0.4, the mouse will allow me to drag and drop with no difficulties at all, and I can also drag and drop with my finger. Using Google Chrome 26.0.1410.64m, I can drag and drop with my finger, but not the mouse.

@tilomitra
Copy link
Contributor

@doulostheou That makes sense. In IE10, we use the MSPointer API which abstracts touch and mouse events. In Chrome, you need to explicitly set two listeners - one for touch, and one for mouse. This is what the dual-listener issue references, and that's what I'm working on to fix for this sprint.

@tilomitra tilomitra closed this Jul 22, 2013
@tilomitra
Copy link
Contributor

Refer to this pull request: #986

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants