Note: 
1) This issue exists on all devices.
2) This issue also exists on al builds of M56, m57 and M58 milestones
3) Please find logs and video @http://go/chrome-androidlogs1/6/701715

tedchoc@, 

Could you please assign this issue to other developers if jdduke@ is unavailable at the moment, thanks!

This is a problem with google plus.  They are drawing their own refresh spinner (if you load the page on desktop chrome with mobile mode emulation via dev tools), you'll see they show the spinner on pull down.

There might be signals they can give to chrome that would prevent our spinner from showing, but aelias@ would definitely know that better than me.

Sounds like we should punish the developer who added pull-to-refresh to Chrome on Android in the first place.

There were a number of workarounds at the time it was added, though I imagine there might be some cleaner APIs for addressing the issue on the Plus side.

No repro on 55.0.2883.105, so I think this is likely caused by the passive document-level listener intervention which launched in M56: https://www.chromestatus.com/feature/5093566007214080

Even with the option off (you can disable it via about://flags) I'm able to get into situations where there are multiple pull to refresh images. You need to do it on first load because it appears the pull to refresh item gets added then.

But it does seem like it is more reproducible with the flags on. The page though is much more responsive in scrolling with the flags on.

Sounds good.  Particularly as there is a preexisting bug and the intervention improves performance, I don't think we should necessarily recommend to G+ team that they mark the listener nonpassive.  Let's tell them to use "overscroll-action" when it ships.