Found this while working on bug 1083395. I haven't verified it can actually manifest in practice, but the code at [1] is intended to consume a tap to stop a fling rather than dispatching the tap through to content. However the code only checks the velocity of the current APZ, while in fact there might be a fling on an APZ higher up in the handoff chain. The CancelAnimations is done on the entire handoff chain so the fling will be stopped, but the tap will still go through. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/AsyncPanZoomController.cpp?rev=c0e4ec5fc709#1031

Comment on attachment 8505687 [details] [diff] [review] Part 2 - Check the entire handoff chain for fast-moving APZCs Review of attachment 8505687 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/apz/src/AsyncPanZoomController.cpp @@ +2332,5 @@ > > +bool AsyncPanZoomController::IsMovingFast() const { > + ReentrantMonitorAutoEnter lock(mMonitor); > + return (GetVelocityVector().Length() > gfxPrefs::APZFlingStopOnTapThreshold()); > +} I can imagine someone reading this method without knowing how it's ultimately used being confused about why "moving fast" is defined as "moving faster than the fling-stop-on-tap threshold", but the alternatives that I can think of (calling the method IsMovingFasterThanFlingStopOnTapThreshold(), or calling it IsMovingFasterThan() and making the threshold a parameter) are unwieldy, so let's go with this. We can probably add a comment in the header, though.

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/ebf448375747 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/d05cd2481d96

https://hg.mozilla.org/mozilla-central/rev/ebf448375747 https://hg.mozilla.org/mozilla-central/rev/d05cd2481d96