Need more responsive tap/click handling globally

[toddparker]

We're currently using click because our original tap events were causing compatibility issues cross-platform, especially on devices like Android and Blackberry that support both touch and cursor based input simultaneously because of the mix of events. The big downside of click is that on iOS and other touch-based devices, the OS will wait about 700ms to see if the user is trying to do a double-tap gesture so each tap feels very laggy.

We've implemented a new event handling scheme on the radiobuttons and checkboxes that feels very responsive. See sample here:
http://jquerymobile.com/test/docs/forms/forms-all.html

The plan is to roll this into a new tap event that is more responsive, then apply this to the remaining widgets (buttons, lists, flip switch, select, slider, etc.) to make everything feel much snappier. Scott J is working on this now.

[scottjehl]

First steps: 977e075

event logger added here:

[toddparker]

Link from Dave M. re: Google's approach to touch event handling:
http://code.google.com/mobile/articles/fast_buttons.html

[davibe]

how is this evolving ? I'd like to contribute but seems that we need to decide how to do it first.

I like the google approach.

[jblas]

Hi davibe,

I started looking into this early last week, but have since switched gears to help fix some bugs so we can get an Alpha 3 out. I created a branch called fastclick, where I was trying to create a plugin that could abstract away the touch/mouse events so that our other plugins could just bind to virtual mouse events and just have it work with touch or mouse events ... note some devices have both. This experiment would also try to normalize the ordering of events across all devices such that something could bind to a click on an element, and then something else could come along and bind to the up of the same element and the callbacks would be triggered in the expected order (up first, then click).

You can see the beginnings here:

https://github.com/jquery/jquery-mobile/tree/fastclick/experiments/fast-click

But I'll probably get back to it right after Alpha3 is released.

• Kin

[jblas]

I should also mention that right now the plugin is invoked with special bind/unbind methods, but we'll likely use special events in the final implementation so that folks can just use standard bind/unbind.

• Kin

[davibe]

I read your code. What do you think about the article from google liked above ?

[jblas]

We will be implementing something similar that kills the default click() that is automatically dispatched when appropriate. As I mentioned earlier, I'm also trying to make it so we can abstract away the other mouse events so that they get dispatched as expected on every device we will be supporting.

The code currently checked in is just a skeleton of the implementation.

[davibe]

wouldn't it be enough for now to fire a custom and fast click event just after touchend (if not moved) and then killing the browser's ghost click coming later ?

[toddparker]

Message from woutervanwijk:

On iOs, I experience a delay when clicking a button or a listview-item. I thought it was just the device being slow, but after reading this: https://github.com/cpojer/mootools-mobile#readme I don't know that anymore. Mootools-mobile provides a touch event handler that automatically replaces all your click handlers with touch events to overcome the ~300ms click delay. It would be very good for the user experience if this would be implemented, imho. Here is more: http://cubiq.org/dropbox/clickdelay.html

[pluggy]

I'm not sure if this is related, but since about the start of February I am experiencing problems with tapping on / off switches and checkboxes (https://github.com/jquery/jquery-mobile/issues/issue/1078). I just wanted to point out the problem in case it is indeed a related regression.

[BMCouto]

Hi jblas,
Did you take a look on this lately?
Cheers!

[jblas]

@BMCouto

Yes, I am actively working on it in the fastclick branch. I'm in the process of converting over all plugins to using the new virtual mouse events.

Feel free to pull that branch and give some feedback

• Kin

[naugtur]

Interesting thing about tap event - on my testing device (an old iPod touch) I consistently get two taps instead of one for any node I use it with. Click event is not doubled. There is a delay between first and second issue of the tap event. Looks like the first one is the real tap and the second one bumps up when click event fires

[dave1010]

I made a jQuery plugin based on Google's fast buttons demo. It's untested and was written in a rush but would be a nice plugin to have if it was polished.

https://github.com/dave1010/jquery-fast-click

[martijnbos]

Hi JBlas, i've just tried out your branch a bit and so far it seems to work fine. There seem to be some problems using it together with google maps though, it becomes very laggy. Could you take a look at this? Or is there maybe a way to turn this functionality off for certain pages?

edit: I originally tested this in Safari 5.0.3.
I just tested it on Firefox 4 and google maps doesn't seem to be lagging there. This might have something to do with the graphics card being used to render stuff though.

[jblas]

@martijnbos

Do you have an example we can take a look at? Also, what platform are you testing on? Have you confirmed that the lag is only on the fastclick branch? What about the HEAD?

http://jquerymobile.com/test/

[martijnbos]

@jblas

Seems this is not an issue after all, I just tested it again in my Safari browser and it seems to be running fine now. It probably had something to do with my CPU usage at that time or something.

[scottjehl]

This landed in today. Great work, Kin!

[mikeymckay]

Is there something that I need to do to take advantage of this? I am still getting horribly slow button response on Android (Color Nook).

[toddparker]

The Nook is a pretty slow device. What specifically is being slow? Just normal button presses?

[mikeymckay]

Button presses. If I create custom buttons with touchstart events instead
then it is great. The built in radio buttons and checkboxes are unusable.

On Fri, Oct 28, 2011 at 5:01 PM, Todd Parker <
reply@reply.github.com>wrote:

The Nook is a pretty slow device. What specifically is being slow? Just
normal button presses?

Reply to this email directly or view it on GitHub:
#854 (comment)

[toddparker]

Our vmouse events use a similar technique but they have to be used carefully because Android has a lot of issues if you use touch events like that on an element that either changes the layout somehow or navigates to a new page. If you can improve performance in your specific app, go for it. We just had to back on on some of this because there are potential issues. I just tested the page on our Nook and although it's not exactly snappy, it's workable.

[mikeymckay]

We are using the app to test children's ability to identify 100 letters in
60 seconds. A person uses the Nook to see mark any errors the child makes,
so it has to be responsive or you get lost. Often it doesn't respond at all

• sometimes you get ghost clicks where the class changes to ui-active, but
  it's not marked as pressed. It is was a big mess really. I am currently
  exploring new approaches. You can see it in action here:

This is the test I made using touchstart:
http://mikeymckay.iriscouch.com/egra/_design/app/index.html?Assessment.Test
Press start to enable the buttons. Only downside with this approach is that
you can't scroll if you click the button.

I don't have a quick URL to show the radio buttons - but if you go through a
few pages of this you will eventually see them. Not only are the buttons
slow, but they don't respond or ghost click about 25% of the time.
http://mikeymckay.iriscouch.com/egra/_design/app/index.html
http://mikeymckay.iriscouch.com/egra/_design/app/index.html?Assessment.The%20Gambia%20EGRA%20May%202011
(the password is not validated - put in anything)

On Fri, Oct 28, 2011 at 5:18 PM, Todd Parker <
reply@reply.github.com>wrote:

Our vmouse events use a similar technique but they have to be used
carefully because Android has a lot of issues if you use touch events like
that on an element that either changes the layout somehow or navigates to a
new page. If you can improve performance in your specific app, go for it. We
just had to back on on some of this because there are potential issues. I
just tested the page on our Nook and although it's not exactly snappy, it's
workable.

Reply to this email directly or view it on GitHub:
#854 (comment)

[toddparker]

Yeah, then responsiveness needs to take precedence over things like scrolling. Like I said, you can make optimizations like this, especially if are targeting a very narrow slice of devices. We've done a ton of work to make things as fast as they can be without getting wonky in certain scenarios/platforms. We'll continue to make things better but it's a complicated problem to solve if you're trying to support a lot of platforms. Android is one of the worst offenders here unfortunately. It's native browser is very buggy.

That said, if you do come up with improvements, please do submit a pull request.