741706 - Calling prevent default on one active touch point shouldn't affect other active touch points

Status: RESOLVED DUPLICATE of bug 742019

(Firefox for Android Graveyard :: General, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

From a code inspection, it seems to me that our code doesn't properly handle calling preventDefault on one touch point but not a second touch point being used at the same time. I don't know if Gecko tracks multiple touch points separately for default-prevention purposes (I'm guessing not based on http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6686) but we also don't selectively drop events based on the touch point that has been default-prevented in LayerController.java.

Comment 1

[Wesley Johnston (:wesj)]

I'm confused by this description. Are you talking about preventing mouse or panning events on a per touch basis? Can you show an example where you think our behavior is wrong (and so that we can compare to other implementations? What do you think is proper?

I think the spec is a bit vague (or incorrect) on this subject, but I'll hold off until I know what you really filed this bug for.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

I'm referring to this part of the spec at http://www.w3.org/TR/touch-events/

If the preventDefault method is called on this event, it should prevent any default actions caused by any touch events associated with the same active touch point, including mouse events or scrolling.

The way I understand this, if the user does the following to generate a sequence of touch events:

1. put finger 1 down
2. put finger 2 down
3. move finger 1 around
4. move finger 2 around
5. lift finger 1
6. lift finger 2

and the page does a preventDefault on step 1, then we should be panning the page on step 4 rather than pinch-zooming the page on steps 3 and 4. does that make sense? i think with our current implementation we will do nothing (i.e. no panning or zooming) on steps 3 and 4 because we'll just throw away all of the events after the first preventDefault, until we get another sequence of touch events.

Am I misunderstanding something?

Comment 3

[Wesley Johnston (:wesj)]

No. I've read it that way before as well. That's what I figured this was. I think I had this conversation with mbrubeck once....

I think that's how the spec reads, but I don't think its that's what the authors meant it to say. And the words "prevent any default actions caused by any touch events associated with the same active touch point" are pretty vague (what does "touch events associated with the active touch point" mean?).

I also don't think it would match the behavior of other implementations (which the spec is basically trying to document), but I can double check tomorrow. If it doesn't match, the issue's better brought up with the working group, but mbrubeck can probably also comment.

Comment 4

[Matt Brubeck (:mbrubeck)]

(In reply to Kartikaya Gupta (:kats) from comment #2)
> 1. put finger 1 down
> 2. put finger 2 down
> 3. move finger 1 around
> 4. move finger 2 around
> 5. lift finger 1
> 6. lift finger 2
> 
> and the page does a preventDefault on step 1, then we should be panning the
> page on step 4 rather than pinch-zooming the page on steps 3 and 4.

This is not necessarily true -- since default actions are implementation-defined, we could say that the default action is panning only if there is exactly one touch point.  In that case, it could be correct to do nothing here.

But I agree with the larger issues and the vagueness of the spec.  It would be good to (a) see what other implementations do, and (b) think about what would be the most useful behavior for content authors.  Are there any practical use cases that would be enabled or prevented by changing this behavior?

Comment 5

[Wesley Johnston (:wesj)]

Attachment: Testcase

This could probably be simplified a lot, but has a few buttons to control whether we call preventDefault on the first or second touch.

My basic test.
1.) Tap the "Prevent on Touch1" button
2.) Tap a finger on the page somewhere
3.) Tap a second finger on the page somewhere
4.) Move the second finger around

In FennecNative and Opera, nothing happens when you move the second finger around. In stock, pinch zoom occurs when you move it (or either finger for that matter). Looking for an iPad. A test on honeycomb or ICS would be helpful as well.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

In Chrome on ICS, the second finger doesn't show up as a touchstart, and moving it around does nothing. Then if I move the first finger, it pinch-zooms the page, and from then onwards the second finger is also able to pinch zoom the page. Kinda messed up if you ask me.

Comment 7

[Wesley Johnston (:wesj)]

iPad with iOS 5.0.1 does not react to the second finger.

We have a bug where, if the page calls preventDefault on the second touchstart, we never fire a touchend event to android for the first touch. That results in completely broken panning.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

(In reply to Matt Brubeck (:mbrubeck) from comment #4)
> But I agree with the larger issues and the vagueness of the spec.  It would
> be good to (a) see what other implementations do, and (b) think about what
> would be the most useful behavior for content authors.  Are there any
> practical use cases that would be enabled or prevented by changing this
> behavior?

Heh, I was just about to start diving through the mailing list to see the discussions that went into writing the spec, and then I noticed that you were the editor for the spec :)

In general it looks like other implementations are all over the place. iDevices probably have the oldest implementations though, and the most-likely-to-be-sane behaviour, so we should find some of those and just copy that. If it turns out that their behaviour is inconsistent, I would lean towards what I described as my interpretation of the spec in comment #2. We should be treating each active touch point as separate all the way through, and the default actions should be based on the number of un-prevented touch points.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

I'm going to close this as a dupe of 742019; the implementation I put into the patch there has a reasonably sane behaviour in that once an event has had preventDefault() called on it, we abort all pan/zoom actions on that event and all future events until all touch points are lifted.