Clicks stop working on iOS 11.3 after resuming

[lasselaakkonen]

I have reproduced this issue with a Cordova app using UIWebView on iOS 11.3 on multiple devices.

According to this discussion, this issue applies to mobile Safari as well:
http://forum.framework7.io/t/ios-11-3-phonegap-resume-problem/2912

To reproduce the issue with Cordova:

• Open app
• Put app in background
• Resume app after 2-5min
  -> click events are triggered with event.timeStamp as a negative number

The negative timestamp is then incremented in successive clicks and clicking starts working when the number has increment above 0.

Framework7 has fixed the issue here:
framework7io/framework7@ac02ad1

I have forked this project and fixed the issue in a similar way here:
https://github.com/lasselaakkonen/fastclick/tree/fix-ios-11-3-event-timestamps

I am not familiar with FastClick internals, are there going to be any issues with using the current time as a timestamp, instead of reading it from the event?

[pollingj]

Thanks so much for this. A massive life saver! 🥇

[Anopetia]

Thank you!!!!

[dimitriadamou]

Thank you, life saver

[toxwj123]

Very thank you, solve my problem

[benmcmaster]

@lasselaakkonen Awesome Thank you!!!

Question: I looked at your branch's diff: why are you checking for iOS 11.3 specifically?

var deviceIsIOS11_3 = deviceIsIOS && (/OS 11_3(_\d)?/).test(navigator.userAgent);

Shouldn't we just use (new Date()).getTime(); globally? What happens in 11.4? Are you assuming it will be fixed?

[lasselaakkonen]

@benmcmaster I do not know how sensitive FastClick is to the changes in timestamps and I do not know how how much of a difference there can be between event.timeStamp and (new Date()).getTime(), so to play it safe and not break any other platforms I made the change only to iOS 11.3.

I am hoping it will be fixed in in iOS 11.4. And it might already be fixed, because I think I had iOS 11.4 beta installed on a device and I could not replicate the issue on that .. if I remember correctly. I could verify that.

[vahvarh]

line 336 you have a bug:
if (deviceIsIOS && targetElement.setSelectionRange && targetElement.type.indexOf('date') !== 0 && targetElement.type !== 'time' && targetElement.type !== 'month' && targetElement.type !== 'email') {

should read

    if (deviceIsIOS && targetElement.setSelectionRange && targetElement.type.indexOf('date') !== -1 && targetElement.type !== 'time' && targetElement.type !== 'month' && targetElement.type !== 'email') {

[lanshengzhong]

Thank you all!!!!

[lasselaakkonen]

@vahvarh I have not modified that line.

(Offtopic: but if you are referring to targetElement.type.indexOf('date') !== 0, it could probably also be !== -1 and it wouldn't change the behavior)

[sergetk]

@lasselaakkonen
I can confirm that 11.4 beta has this issue

[lwenke]

The comment said "iOS 11.3 returns negative values for event.timeStamp after pausing/resuming a Cordova application". If that is true, what about this fix?
touchStartTime = (event.timeStamp < 0) ? (new Date()).getTime() : event.timeStamp;
I was hoping there could be a fix that would still work if it was using iOS 11.4 and the bug still existed.

[rmondello]

It's great that there's a workaround for this! Has anyone filed a bug at the WebKit project bug tracker (https://bugs.webkit.org) or Apple's bug tracker (https://bugreport.apple.com)?

[cdumez]

I filed https://bugs.webkit.org/show_bug.cgi?id=185040, I am looking into this bug. Thanks.

[zmen]

In my case, event.timeStamp doesn't return negative value, but it indeed became smaller than lastClickTime after resuming. Once resuming, it increased normally.
So I think instead of checking timeStamp negative or replace it with new Date().getTime(), we may just do this:

    // if (event.timeStamp - this.lastClickTime < this.tapDelay) {
    if (event.timeStamp - this.lastClickTime < this.tapDelay && event.timeStamp > this.lastClickTime) {
      event.preventDefault();
    }