focus triggered on incorrect field after scroll.

[tokafish]

Hi everyone,

We're using fastclick in an iOS web application, and are encountering an issue with focus and fastclick.

See the fiddle here:

http://jsfiddle.net/xJrsW/

open this URL in iOS: http://jsfiddle.net/xJrsW/embedded/result/

The problem occurs when the iPhone scrolls as a part of focusing the field.

1) I scroll the to the very top of the document: 2) I tap (and hold) on textfield 3, then release 3) textfield 5 focuses

the problem is intermittent, and a simple quick tap on #3 does not cause the problem.

Any ideas on what might be going on?

Thanks!

[mattcg]

Thanks for reporting and for the excellent example. I'm able to reproduce this on iOS5 in the simulator.

[mattcg]

Implemented a workaround, even if I'm not very happy with it. @wless1 will you verify that this fixes the issue please?

[tokafish]

Awesome, works perfectly. Didn't realize the problem was that it was focusing something that would already be getting focus due to a delayed click.

Much improved user experience!

On Thu, Nov 29, 2012 at 4:46 PM, Matthew Caruana Galizia < notifications@github.com> wrote:

Implemented a workaround, even if I'm not very happy with it. @wless1https://github.com/wless1will you verify that this fixes the issue please?

— Reply to this email directly or view it on GitHubhttps://github.com/ftlabs/fastclick/issues/36#issuecomment-10873634.

[mattcg]

Thanks :)

The workaround is a bit hacky - hopefully there's a more long term solution that will fix both this issue and issue #32.

[jeybe]

@mattcg this did not at all solve it for me, it merely made things worse. Now the focus is jumping around among the input fields.. Alas, this issue has not been solved and should not be closed.

[mattcg]

@jeybe has the behaviour improved with the last commit?

[ProcuraIsaac]

This is similar to #42.

[mattcg]

Is anyone able to replicate this issue? Because I can't.

[vhmth]

I can't repro on iOS6 simulator (from the jsfiddle at the top).

[Pointy]

If you're still tweaking this, I'm noticing that on Android 4.x devices (an HTC One X with 4.0.3 and a Nexus 7) in Chrome that the 100ms "fudge factor" is a little long in the case of taps on elements. When I drop that to 75 (seems trivial, I know), the success rate for tapping on elements goes way up. At 100, I get the select popup only very rarely (maybe one try out of 20).

Oddly enough, when the value was set at 100, I noticed that though it was really hard to get a to respond, once it did respond then subsequent taps tended to work far more reliably for that element only. (I have three select elements adjacent to each other, a "month" - "day" - "year" thing.) I'm still trying to figure out how/why that happens.

mattcg commented 11 years ago

Re-opening this pending investigation of new report by @Pointy

Pointy commented 11 years ago

Trivial test page for what it's worth: http://jsbin.com/uvukuk/1

This may be something that's a personal habit issue. I tend to tap lightly and quickly (and apparently the person doing the QA on my own app does too :-). With the 100ms delay, a "slow tapper" might have no problems, or problems only rarely.

lazd commented 11 years ago

When you have multiple items in a list that you want to select, and you tap two of them very quickly, the following code causes the second tap to have no effect:

if ((event.timeStamp - this.lastClickTime) < 200) {
    event.preventDefault();
}

Commenting out this code makes it possible to select multiple items as expected.

JSBin illustrating the problem: http://jsbin.com/efifit/1

iPad running iOS 6.0.1 (10A523).

john-bai commented 11 years ago

I've noticed that css styles can delay the touchend event firing, resulting in a missed fast click opportunity (>100ms diff between touchstart and touchend) I'm using bootstrap css styles in my project and noticed this with input type="text" elements:

without css:
in onTouchStart. touchstart timestamp: 1372631407522
in onTouchEnd. touchend timestamp: 1372631407568

with css:
in onTouchStart. touchstart timestamp: 1372631534562
in onTouchEnd. touchend timestamp: 1372631534695
touchend was too delayed from the trackingClickStart (>100ms)

diff without css: 46ms
diff with css: 133ms

wizza-smile commented 10 years ago

the long touch is firing two click events. the natural one and the synthetic one. Which makes fastclick useless for some cases. Is there any idea why the longtouch is treated differently from a tap? this is applies to needsfocus == true || false

jdurand commented 9 years ago

I was able to fix this in my app by canceling the synthetic click for text and textarea inputs :

@@ -522,6 +522,13 @@
    FastClick.prototype.onTouchEnd = function(event) {
        var forElement, trackingClickStart, targetTagName, scrollParent, touch, targetElement = this.targetElement;

+       // Takes care of https://github.com/ftlabs/fastclick/issues/36
+       if(deviceIsIOS &&
+               targetElement.nodeName.toLowerCase().match(/input|textarea/) &&
+               targetElement.type.toLowerCase().match(/text|textarea/)){
+           return false;
+       }
+
        if (!this.trackingClick) {
            return true;
        }

This probably doesn't scale to all use cases but I think it's a start.

ghost commented 8 years ago

This causes an issue in iOS when time is changed to a previous date. I was thinking about taking the absolute value in

if (Math.abs(event.timeStamp - this.lastClickTime) < 200) { event.preventDefault(); }

Could that cause other problems?

zhe-he commented 7 years ago

hi, everyone: when I use 'vue'. some dom like it : <p @click="active=!active" :class="active?'active':''">toggle</p> and use 'fastclick' like it: FastClick.attach(document.body)

I quickly click 'P' two times. the chrome F12 is warn: Unable to preventDefault inside passive event listener due to target being treated as passive.See https://www.chromestatus.com/features/5093566007214080;

so, I use the @jdurand method. such as :

// Prevent phantom clicks on fast double-tap (issue #36)  
     if ((event.timeStamp - this.lastClickTime) < this.tapDelay) {
        var target = event.target || event.srcElement;
        if(target.nodeName.match(/input|textarea/i)){
            event.preventDefault();
        }
    };

Could your change the @@ 444,4~451,4 @@ code? thanks!

the demo: http://jsbin.com/vesutagiwo/edit?html,css,js,output.

You may need to save locally to see warn.

aoki42 commented 7 years ago

Same as above . Need to solve

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[mattcg]

Re-opening this pending investigation of new report by @Pointy

[Pointy]

Trivial test page for what it's worth: http://jsbin.com/uvukuk/1

This may be something that's a personal habit issue. I tend to tap lightly and quickly (and apparently the person doing the QA on my own app does too :-). With the 100ms delay, a "slow tapper" might have no problems, or problems only rarely.

[lazd]

When you have multiple items in a list that you want to select, and you tap two of them very quickly, the following code causes the second tap to have no effect:

if ((event.timeStamp - this.lastClickTime) < 200) {
    event.preventDefault();
}

Commenting out this code makes it possible to select multiple items as expected.

JSBin illustrating the problem: http://jsbin.com/efifit/1

iPad running iOS 6.0.1 (10A523).

[john-bai]

I've noticed that css styles can delay the touchend event firing, resulting in a missed fast click opportunity (>100ms diff between touchstart and touchend) I'm using bootstrap css styles in my project and noticed this with input type="text" elements:

without css:
in onTouchStart. touchstart timestamp: 1372631407522
in onTouchEnd. touchend timestamp: 1372631407568

with css:
in onTouchStart. touchstart timestamp: 1372631534562
in onTouchEnd. touchend timestamp: 1372631534695
touchend was too delayed from the trackingClickStart (>100ms)

diff without css: 46ms
diff with css: 133ms

[wizza-smile]

the long touch is firing two click events. the natural one and the synthetic one. Which makes fastclick useless for some cases. Is there any idea why the longtouch is treated differently from a tap? this is applies to needsfocus == true || false

[jdurand]

I was able to fix this in my app by canceling the synthetic click for text and textarea inputs :

@@ -522,6 +522,13 @@
    FastClick.prototype.onTouchEnd = function(event) {
        var forElement, trackingClickStart, targetTagName, scrollParent, touch, targetElement = this.targetElement;

+       // Takes care of https://github.com/ftlabs/fastclick/issues/36
+       if(deviceIsIOS &&
+               targetElement.nodeName.toLowerCase().match(/input|textarea/) &&
+               targetElement.type.toLowerCase().match(/text|textarea/)){
+           return false;
+       }
+
        if (!this.trackingClick) {
            return true;
        }

This probably doesn't scale to all use cases but I think it's a start.

[ghost]

This causes an issue in iOS when time is changed to a previous date. I was thinking about taking the absolute value in

if (Math.abs(event.timeStamp - this.lastClickTime) < 200) { event.preventDefault(); }

Could that cause other problems?

[zhe-he]

hi, everyone: when I use 'vue'. some dom like it : <p @click="active=!active" :class="active?'active':''">toggle</p> and use 'fastclick' like it: FastClick.attach(document.body)

I quickly click 'P' two times. the chrome F12 is warn: Unable to preventDefault inside passive event listener due to target being treated as passive.See https://www.chromestatus.com/features/5093566007214080;

so, I use the @jdurand method. such as :

// Prevent phantom clicks on fast double-tap (issue #36)  
     if ((event.timeStamp - this.lastClickTime) < this.tapDelay) {
        var target = event.target || event.srcElement;
        if(target.nodeName.match(/input|textarea/i)){
            event.preventDefault();
        }
    };

Could your change the @@ 444,4~451,4 @@ code? thanks!

the demo: http://jsbin.com/vesutagiwo/edit?html,css,js,output.

You may need to save locally to see warn.

[aoki42]

Same as above . Need to solve