I'm unable to reproduce this, trying both techcrunch.com and slashdot (as in the previous bug). I've tested both with mouse-wheel scrolling, and with a track-pad (using a CrOS build running on Linux).

What device are you seeing this with? Does it reproduce on just that device, or multiple devices?

I see it on a Chromebook Pixel 1 on Dev channel, with either --site-per-process or TDI enabled in about:flags.  I just repro'd it on a separate Chromebook Pixel 2 on 58.0.3029.140 running --top-document-isolation.  (Note: I don't think we merged the fix for  issue 701178  to M58, fwiw.)

The most reliable way for me to repro it is:
1) Reload techcrunch.com and let it finish loading.
2) Scroll down so the blue reCAPTCHA box is visible on the right, and move the cursor over it.
3) Wait 1 second, then try to two-finger scroll on the trackpad.

More often than not, it won't scroll the page.  If you lift your fingers and then try to two-finger scroll again, it does scroll the page.

It *does* repro with a mouse wheel if I attach a mouse.  (I didn't think so at first, but I just found a case that it did.)

Ok, I'll update my Pixel 1 and give it a try.

Ok, I can see it on my Pixel 1, but (i) only on the ReCaptcha blue box, and (ii) only intermittently. It seems almost to be related to when the mouse cursor changes from insertion bar to hand to arrow. Scroll failure always coincides with the arrow icon. I find it also seems to happen only as the arrow pointer crosses the edge of the blue box.

I still can't repro it on the desktop CrOS build.

Desktop vs Pixel differences may be due to compositing. Have you tried --enable-prefer-compositing-to-lcd-text?

+ sahel@ in case there are recent changes to wheel scroll latching that might be relevant here.

I'm curious whether the differences between device and desktop could be due to some sort of race?

Btw, I did try the flag bokan@ suggested on my desktop build, but results were inconclusive at best.

I haven't landed any cl that might affect OOPIFs, yet. Besides, my changes are all behind the TouchpadAndWheelScrollLatching runtime flag. I won't expect any regressions when the flag is disabled (by default).

ScrollAnimation though is broken with OOPIFs maybe some how scroll happens to follow the animation path rather than the one that it would go through normally.

ScrollAnimation is *not* broken with OOPIFs, but there is an issue with the current test not working due to an unrelated bug, https://bugs.chromium.org/p/chromium/issues/detail?id=710513.

That's why SitePerProcessBrowserTest.ScrollBubblingFromOOPIFTest currently limits itself to the non-animated case.

I see, thanks for the correction!

Update to my repro steps in comment 2, on 61.0.3163.123 on a Chromebook Pixel 2 with --site-per-process.

The issue has changed a bit.  If I start a trackpad scroll with the arrow over main frame, the scrolling immediate stops when the OOPIF scrolls underneath the arrow.  Continued trackpad scrolling does nothing until I lift my fingers, and then it works again whether I start where I am (over the OOPIF) or elsewhere.

It's a bit worse on this simple page:
http://csreis.github.io/tests/cross-site-iframe.html
If you click "Go cross-site (complex page)," we load the waterfall page in the OOPIF.  The tree status bar near the top is itself an OOPIF.

If you put the arrow above the tree status and start to scroll down the page with the trackpad, reaching the tree status OOPIF will again halt the scrolling.  However, scrolling doesn't work when over the tree status OOPIF whether you lift your fingers and try again or not.

wjmaclean@: Any chance you can take another look when you get back?  This seems important to fix.

I'll take a look today and see if I can figure out what's going on.

So it seems this issue is fixed by the WheelScrollLatchingAndAsyncWheelEvents Finch trial that is currently running ... creis@'s device did not have this trial enabled and mine did, explaining why he could reproduce the issue and I could not.

This feature is slated to be turned on by default in M65. I don't think it's worth trying to come up with a shorter-term fix for OOPIF, but if I'm wrong let me know.

I'm going to marked this as fixed now that scroll-latching is on by default for M-65. Please re-open if I'm wrong about this.

Just verified the fix on ChromeOS 65.0.3319.0, which includes the scroll-latching enabling (r528134).  Thanks!