Announcement

**Isomorphic** · 16 Oct 2018, 13:10

In the original thread where you reported this, you said it affected some Android devices. Does this reproduce on PhoneGap for Android, or only on iOS? It looks like you specifically stated that the other issue (involving scrollbars) did not reproduce on PhoneGap for Android.

**Developer12145** · 17 Oct 2018, 01:02

Yes, the "recordClick" issue affects both PhoneGap for iOS and PhoneGap for Android! The issue (involving scrollbars) affects only PhoneGap for iOS!

**Isomorphic** · 17 Oct 2018, 14:01

We are able to reproduce this and are looking into it.

**Isomorphic** · 24 Oct 2018, 10:19

First, please note that both issues you've reported with PhoneGap are really bugs arising from the WebView layer. We'll discuss them both here and link the other thread to this one to avoid duplication.

Apple has reportedly already deprecated UIWebView in iOS 12, and it may be removed in iOS 13 according to this, so our recommendation is for you to update your PhoneGap project to use WKWebView, which is now an officially supported plugin of PhoneGap. The GitHub page and install instructions are here.

WKWebView is an Apple API, so for Android our recommendation is to report the behavior to Google as bugs so that it may be potentially fixed in the future. There are some unofficial solutions here such as the "Crosstalk" plugin, but it's up to you whether they are appropriate.

Now, let's consider whether the Framework can work around WebView's bugs:

In the case of the scrollbar thumb "jumping," we don't receive any events during a momentum scroll after the touchEnd, until it completes with an onscroll event. That final onscroll may be up to 3 seconds after the touchEnd. Moreover, during that time, the DOM is frozen and the element's scrollTop isn't updated. So there's no way for the Framework to detect that a momentum scroll is in progress, and thus no way for the Framework to correct the jump. (So your best bet is to upgrade your iOS PhoneGap project to use the WKWebView plugin as mentioned above.)
In the case of tap-to-stop generating an unwanted click, the Framework normally doesn't receive this click so doesn't have to deal with it - that's true for iOS mobile Safari and Android Chrome. In WebView, we receive a touchStart/touchEnd for tap-to-stop so we have to use the onscroll event to attempt to recognize and block the unwanted click. Sometimes we receive the onscroll event after the touchStart and before the touchEnd, so we've added logic to our EventHandler to cancel the click in this situation.
However, while testing various devices, including simulators, we've seen that you don't always get an onscroll event before the touchEnd, which means our workaround may not always prevent the unwanted click. However, on a fast device it may work - you'll have to check. The only way to prevent the unwanted click 100% would be to delay every click on a scrollable element for up to 500ms to wait for the final onscroll event, which would cancel the click. However, this would have a very negative impact on usability, so we've chosen not to pursue such an approach.

The workaround we have added will be applied to SGWT 6.1p/SC 11.p and newer releases, and will be in the nightly builds dated 2018-10-25 and beyond.

Announcement

recordClick event fires very early on touch devices using Phonegap

Comment

Comment

Comment

Comment