Yup, this looks like it's probably the root listener intervention.

This could be fixed trivially with touch-action, but is a great example of scary breakage due to this intervention.

No I don't think this is the root listener intervention. The touch listeners aren't on a root element.

My best guess is that this is non-blocking event listeners during fling? And that is causing overscroll? I can try tomorrow.

cc'ing lanwei@

Dave and I tried on different Android devices with PassiveEventListenersDueToFling enabled, neither of us can reproduce the problem. Could you please explain in more details how you reproduce the pull to refresh, and did you see it happen on other pages, thank you?

This is a 50/50 Finch trial. So likely we are unlikely in the control group. 

I tested even when I made all the touch starts passive, I still did not see any pull to refresh. The page calls PreventDefault on all the touch moves, so there is no fling gesture. I guess this is not our touch event intervention.  

Dave's root scroller intervention will also make touchmove listeners passive - it could be that.  p2r should trigger only if the document has overflow and is at scrollTop=0 (see https://docs.google.com/document/d/12Ay4s3NWake8Qd6xQeGiYimGJ_gCe0UMDZKwP9Ni4m8/edit).

I thought all the handlers were added to a div. And not the body, document or window. So it wouldn't be the root scroller intervention at all. 

This can no longer be reproduced with Chrome M58. Closing stale issue.