It seems like it can get stuck at the top or bottom after scrolling through it the first time.

This might be caused by the new preventDefault behavior that bug 1193062 introduced - calling preventDefault on a single scroll event will now cancel the whole scroll gesture. It's not clear whether that was a good idea.

I was able to repro this. It has to be repro'd in the hangouts contacts pane, which requires (AFAICT) a non-enterprise gmail account. From the log it doesn't look like it's a preventDefault that's causing it, more like the pan gesture block is getting prematurely discarded. I'll investigate.

I was wrong, it is a preventDefault that's causing it. The pan gesture block gets interrupted and so subsequent events are not processed in APZ until a new pan gesture block starts.

I discussed this with Markus and Botond and I think the way forward here is to treat pan inputs much like we do wheel inputs in the APZ. That is, a preventDefault for a pan input should just cause us to start new pan input block rather than dumping the rest of the inputs in that block. Right now once a pan input block is "interrupted" it basically goes away and the rest of the inputs go into the APZ black hole at [1] - they still get sent to content but with a 0 input block id which is not good, and they are ignored in the APZ code. I wrote patches to just create a new pan input block and it fixes the problem. Try push at [2]. [1] https://dxr.mozilla.org/mozilla-central/rev/0babaa3edcf908c393b68a3dc2d1c2a2450c31ed/gfx/layers/apz/src/InputQueue.cpp#329 [2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=e96fb5c416b1

https://hg.mozilla.org/integration/mozilla-inbound/rev/6847b131a14b https://hg.mozilla.org/integration/mozilla-inbound/rev/3e5a07114c82

https://hg.mozilla.org/mozilla-central/rev/6847b131a14b https://hg.mozilla.org/mozilla-central/rev/3e5a07114c82