I abandoned the previous changeset (with a comment of why). I have a new WIP that tracks absolute touch coordinates. This should allow us to use APZ's established heuristics and not reinvent them badly.

Comment on attachment 9036821 [details]
Bug 1515774 - Add screen offset to APZ for better touch interpretation.

I don't know how to do this in Phabricator.. just soliciting feedback before I clean this up more. AFAIK the two things I didn't resolve here are:

1. Updating the velocity with the screen offsets. This works, often. But if the nested scroll snaps back the APZ still starts a fling and it looks bad. I kind of think this is low priority because the velocity is usually set fine when the user flings past the nested scroll.
2. One finger pinch-zoom. It is just a bit chaotic with a dynamic toolbar, but not terrible. The GeckoView might need to be explicitly "pinned", that may require a bunch of messaging from APZ. Not a priority, imho.

It would help understand the patch better if there was an explanation somewhere (here in the bug, in the commit message, in a code comment...) of what the offset being added represents :)

(In reply to Botond Ballo [:botond] from comment #7)

It would help understand the patch better if there was an explanation somewhere (here in the bug, in the commit message, in a code comment...) of what the offset being added represents :)

The offset represents the top-left screen coordinate of the GeckoView. If its parent is being actively scrolled it changes on each touch move (for example, with a disappearing toolbar, the y value will change.)

When we calculate distances, we need to factor those offsets in. We can't store the offset in the APZ's transform matrix because it would apply the same offset to all points uniformly and won't account for the position change.

Does that make sense? After sleeping on it, I think I am doing AsyncPanZoomController::TouchEventOffset wrong, but I get dizzy just thinking about all these coordinate spaces :)

The basic goal of the patch is to calculate pan distances and gesture detection based on the physical finger interaction on the screen, and not have it be relative to the GeckoView (which could be moving under the user's finger).

Comment on attachment 9036821 [details]
Bug 1515774 - Add screen offset to APZ for better touch interpretation.

(I wrote the feedback in Phabricator)

We currently use ParentLayer pixels in GestureEventListener, it should
be Screen pixels because we care about physical distances and
thresholds, not layer-relative ones.

Depends on D17042

Depends on D17043

In Android the embedded GeckoView can be in a scrolling parent, and move
along with the user's finger. In order to intepret touch movements for
gestures, we need to account for the device position of each touch.

Depends on D17044

Backed out 4 changesets (Bug 1515774) for mochitest failures at test_group_touchevents-3.html and test_touch_action.html.

Backout: https://hg.mozilla.org/integration/autoland/rev/031ad7f5577472b87d0172d54e9dcc40dbb4a842

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=45c6f07160d9c0b7a472c68ff63d4aaa9bd00304&selectedJob=224866489

Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=224866489&repo=autoland&lineNumber=4969
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=224851433&repo=autoland&lineNumber=3060

https://hg.mozilla.org/mozilla-central/rev/f6d635be8ffc
https://hg.mozilla.org/mozilla-central/rev/48a4ac1ba700
https://hg.mozilla.org/mozilla-central/rev/2e07c6788179
https://hg.mozilla.org/mozilla-central/rev/422db058e1cf