I discovered this while trying to reproduce bug 1191573. STR: 1. Load http://people.mozilla.org/~bballo/iframe.html in the Browser app. 2. Pan the page around a bit. 3. Shortly after releasing the pan (e.g. while the fling is still in progress) pinch the page. Expected results: The page zooms in response to the pinch gesture. Actual results: The page just pans, as if one of the touch points of the pan gesture was being ignored. Releasing the fingers, waiting a bit, and then pinching again results in zooming successfully.

The problem seems to be correlated with the root content APZC getting into overscroll between the pan and the (attempted) pinch.

The problem is that if you put down a second finger while overscrolled, that touch is ignored completely. This was introduced in bug 1022719. Part of the justification for that behaviour was that it's analogous to the way we ignore a single finger that's put down while overscrolled [1]. However, *that* behaviour was removed in bug 1042103, so we may want to revisit the second-finger-down behaviour as well. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1022719#c24

I propose the following slightly modified behaviour: - If we're panning into overscroll with the first finger when a second finger goes down, continue to ignore the second touch. - If we're in an overscroll animation and two fingers go down, cancel the overscroll animation and pinch as usual. The rationale is that if a user scrolls to one end of the page and then quickly wants to zoom, they're likely to put down the two fingers while the overscroll animation is still in progress, and it would frustrate the user to not be able to zoom. Distinguishing between the two cases is slightly tricky, because in practice the two fingers of a pinch are detected by the hardware at different times, so what we typically see is first a single touch, which cancels the overscroll animation, and only subsequently the multi-touch. I propose distinguishing by whether we're in the PANNING vs. the TOUCHING state: when we process the single touch and the overscroll animation is cancelled, we go into the TOUCHING state, and only enter the PANNING state if the first finger moves by the pan threshold amount before the second finger goes down, which is unlikely to happen in a typical pinch gesture. Kats, what do you think about this approach?

(Nothing specific to Aries here, that's just what I was testing with.)

To be honest I'm not really a fan of making this behaviour even more conditional than it already is. Since we now no longer ignore touch blocks while in an overscrolled state, I think we should also stop ignoring the second touch if we're panning into overscroll with one finger. In other words, don't ignore touches ever. That being said I'm not sure this is a very high priority bug at the moment so I'm not sure it's worth spending a lot of time on. We should find out if bug 1191573 is a regression or Aries-specific or something though.

What do you envision happening when the second finger goes down while the user is panning into overscroll - is the overscroll cleared right away?

In an ideal world I would want the overscroll to remain, and to transition into a zoom state. You could then reduce overscroll on the root scrollframe by zooming in, or when you let go the overscroll will be released. I realize this is probably not going to happen ever but it would be the most intuitive-feeling behaviour :) (Sorry if this isn't very useful, my brain is fried from dealing with the different reference frames in the dynamic toolbar rewrite...)

I agree that what you described would be ideal, though some details would need to be worked out (e.g. what happens if you zoom out?). However, I think the current behaviour of having a pinch gesture started during an overscroll animation be interpreted as a pan, is fairly annoying for the user, and is worth a quick workaround, even if it's not the ideal solution.

Bug 1193930 - Allow the user to start a pinch while an overscroll animation is still in progress. r=kats

This is the quick workaround that I had in mind which is not the ideal solution that you described, but avoids the annoying behaviour that prompted me to file this bug.

Try push that includes this patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6a17db6f030e