Click performance on Android devices (ionic.tapElement changes)

[tmiskin]

Click performance on Android devices for items with hrefs significantly degraded from the changes made to ionic.tapElement recently. I verified on multiple devices that the problem was occurring and then they went away when I reverted ionic.tapElement to the March 19th commit - 26c8f30 and everything was back to the performance of .9.27. Tap responsiveness is slower with the new changes and sometimes you have to click 2-4 times on elements for the click to register. I haven't had the time to narrow it down to what changed that is causing the issue, as there were significant changes to it over the last week.

[mlynch]

Hey, could it possibly be that you are clicking several times in
succession? Try tapping, then waiting half a second, and tap again. Both
taps should be fast.

if not, that's an issue we need to fix (the delay in this case is to avoid
ghost clicks that some platforms unfortunately send)

On Sat, Mar 29, 2014 at 5:43 PM, tmiskin notifications@github.com wrote:

Click performance on Android devices for items with hrefs significantly
degraded from the changes made to ionic.tapElement recently. I verified on
multiple devices that the problem was occurring and then they went away
when I reverted ionic.tapElement to the March 19th commit - 26c8f3026c8f304e7d9d24006d17fcb4161195717ca26a0and everything was back to the performance of .9.27. Tap responsiveness is
slower with the new changes and sometimes you have to click 2-4 times on
elements for the click to register. I haven't had the time to narrow it
down to what changed that is causing the issue, as there were significant
changes to it over the last week.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/970
.

[tmiskin]

I just changed it back to the most recent changes (beta 1) and ran it on my device. First click I made on an element after it loaded (simple 'a' with href) didn't register. I waited a few seconds, clicked again and it registered. When navigating around the app the issue occurs randomly. It happens on any link including the ionic provided back button. When I move back to the mentioned commit, I have never seen a tap not recognized. I can duplicate it every time on multiple devices.

[mlynch]

Okay, let's patch @adamdbradley in here. Adam, are you there? Adam?

On Sat, Mar 29, 2014 at 5:57 PM, tmiskin notifications@github.com wrote:

I just changed it back to the most recent changes (beta 1) and ran it on
my device. First click I made on an element after it loaded (simple 'a'
with href) didn't register. I waited a few seconds, clicked again and it
registered. When navigating around the app the issue occurs randomly. It
happens on any link including the ionic provided back button. When I move
back to the mentioned commit, I have never seen a tap not recognized. I can
duplicate it every time on multiple devices.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/970#issuecomment-39011919
.

[tmiskin]

I believe I found the issue. It is on this commit specifically - 60e4533

In the isScrolledSinceStart function you took it from checking for a change of 15 for scrolling to 2. That is a big jump, and I noticed that the issues occurred primarily when I was using my thumb to navigate. With the thumb and certain screens the travel can definitely be more than 2 because of the compression of the finger and/or roll, and should still count as a tap. When I change the lines back to HIT_RADIUS (or 15) all the clicks are recognized again instead of being counted as a scroll. This issue exists on both my S3 and an S4 but it doesn't happen on an HTC One or our iOS devices. Probably differences in how they recognize/send touch events. Would it be helpful if I messed around with that number until it isn't an issue any more? Maybe start at 2 and work up until I don't see it anymore? Probably want to give it even more buffer than that for fat fingers too.

[adamdbradley]

@tmiskin Yes it would be extremely helpful if you changed the number from 2 up to 15 and see if that fixes this issue. There were a few changes around that time (and from the commit you sent some of it was changed again later) so hopefully what you described is the issue and not something else. Please keep us informed on your tests and I'll play around with it too. Thanks.

[tmiskin]

Sorry, I must not have been clear. Changing it to 15 did fix the issue for me. I was asking if I should try in between 2 to 15 to find the right distance.

[adamdbradley]

If it fixes the issue I see no reason I can't put it back. If I remember correctly, I changed it to 2 because it was easy to scroll down, then scroll back up to the original spot and fire off the click. In that scenario, if you scrolled down and then up it shouldn't execute the click.

I'll change it back to 15, but see if there another way to accomplish this.

[adamdbradley]

@tmiskin Would you be able to verify this change fixes this issue? Thanks

[tmiskin]

@adamdbradley Yes, that fixes the issue.

[adamdbradley]

Awesome, thanks for creating the issue and testing it!