FastButton makes mouse stop working on touchscreen laptops
RByers opened this issue · 4 comments
The FastButton code seems to assume that touch screen support implies there is no real mouse. This has the effect of causing mouse clicks to stop working in Chrome on touchscreen laptops (eg. Win8, Chromebook pixel). See here for more details and how to test: https://plus.sandbox.google.com/115788095648461403871/posts/6RqRCEVbqpC
The FastButton code handles both touch and mouse click events, and does not assume one or the other based on feature detection - it adds listeners for both, then cancels the click if touch fires first.
Are you reporting a definite problem in Chrome on win8 etc, or are you supposing there will be a problem? :)
I can try and take a look if so, but I don't have a real device to test on (have to rely on force enabling touch in chrome).
P.S - correct link is: https://plus.google.com/115788095648461403871/posts/6RqRCEVbqpC
Thanks for the response! I'm glad to hear this isn't the typical pattern I posted about (I didn't dig in detail - seen this pattern too many times).
I noticed the issue by trying (and failing) to click on links on this site on my Chromebook pixel: http://craigerrington.com/blog/arm-chromebook-chromeos-and-xfceubuntu-at-the-same-time/
Debugging into the code, this chunk is getting hit cancelling the click event:
MBP.ghostClickHandler = function (event) {
if (!MBP.hadTouchEvent && 'ontouchstart' in window) {
// This is a bit of fun for Android 2.3...
// If you change window.location via fastButton, a click event will fire
// on the new page, as if the events are continuing from the previous page.
// We pick that event up here, but MBP.coords is empty, because it's a new page,
// so we don't prevent it. Here's we're assuming that click events on touch devices
// that occur without a preceding touchStart are to be ignored.
event.stopPropagation();
event.preventDefault();
return;
}
I see this code has changed in the current version to have a UA check for Android, so presumably it's fixed now. If you point me at an example site using this version of the code I can double-check.
By the way, ideally you'd just disable the fastclick support on Chrome desktop entirely - we don't (and never will) delay click events on desktop. We're also reducing the scenarios where we delay clicks on Chrome for Android too.
If you could find time to download the latest version of MBP and quickly test fastButton locally it would be greatly appreciated - it is probably quicker than me trying to publish a temporary URL somewhere. I don't think there is a problem with it, but a first hand check would help us out a lot.
MBP is really intended for mobile web apps and things like fastButton are not really intended for desktop, but ensuring compatibility everywhere possible is a good thing.
Ok, I'm going to close this issue for now as I'm not convinced there actually is an issue yet. If someone can verify a bug with the current version of fastButton then we can re-open the issue.