Correction: Step 2 should be to just wait for some content to show up in the iframe. In fact, I think the scrolling stops just when the iframe fully loads.

Also happens in ChromeOS

65.0.3325.89 (Official Build) beta (64-bit)
10323.39.0 (Official Build) beta-channel samus
Google_Samus.6300.276.0

Happens in Hangouts Extension pop-out and Zendesk very frequently.  Built in Touchpad still responsive in ChromeOS incident, and you can Highlight + Drag to bring scroll functionality back.

Issue experience occurs in new Calendar:
Scrolling issue within calendar after updating to the latest version. Scroll skips months eg. When attempting to scroll from one month to the next, Feb jumps to May and I have to refresh the page to access March.  There have been instances that the text on the page vibrates until the page is refreshed and other instances where scrolling freezes altogether.
These scrolling issues seem to be sporadic, with no noticeable pattern. Calendar seems to work properly 75% of the time needing to be refreshed roughly 3-4 times a day.

I haven't been able to repro on Linux or Windows but I don't have a Mac or CrOS handy. This does indeed seem like it's OOPIF related. Assigning to wjmaclean@ to investigate.

Reporters: are you using low or hi-dpi screens (hi-dpi == window.devicePixelRatio >= 1.5)? Does the repro occur on the alternate?

Strange ... I'll start looking at this now ...

I've only tested on the Pixelbook and a Macbook Pro with a retina screen, so just  hi-dpi screens.  I don't actually have easy access to a lo-dpi screen (strange problem to have) so not sure about that.

I can repro this with DSF=1 on Linux.

Adding SiteIsolation label per comment 4.  Can someone confirm if the issue occurs when there are subframe processes in Chrome's task manager (with Site Isolation) and goes away when Site Isolation is not enabled?

I was looking at this yesterday with James and yes it is an OOPIF bug.

So here's a weird (and unsettling) observation:

The description above provides both a repro and no-repro case, and I've tried them both (on Linux, ToT). The repro case fails predictably, and the no-repro case seems to work as expected, for as long as I'm willing to keep wheel scrolling it.

** Except if I load the repro case and the no-repro case together. In that event, the no-repro case in fact fails in the same way as the repro case, and it does it pretty immediately.

Important: both cases load pages from the same cross-site domain, so they render in the same process.

Also: If I load two no-repro tabs (so again they're sharing a renderer), then all is fine.

It seems weird (and disturbing) that two isolated frames can affect each other in this way when they're in the same renderer ...

A further comment: I can confirm the events are making it to EventHandler::HandleWheelEvent(), so it doesn't seem to be an issue with the event not propagating from the browser process to the renderer.

One more observation:
Scrolling does not necessairly have to be "Slow".  I often whip the wheel to goto the bottom of a screen and this occurs.

Also - the Touchpad (two finger scroll) scrolling continues to work (on ChromeOS at least), only affecting proper mousewheel.

I can repro this in both 67.0.3364.0 and 64.0.3282.167 on Windows.  Marking as a launch blocker.

mcnee@, can you help triage this or find an owner while James is OOO?  Thanks!

This seems like a substantial blocker to rolling out OOPIFs to all Chrome users. It severely affects our product (Mixmax.com). What Chrome version will OOPIFs be rolled out to all users? Will this be fixed before then?

A few observations so far:

In the no-repro case, the child either acks the GSB with NOT_CONSUMED or NO_CONSUMER_EXISTS, and the root acks with CONSUMED, as we would expect.

In the repro case, the root may ack that GSB with CONSUMED_SHOULD_BUBBLE. So the compositor thread in the root is handling the events even though they should go to the main thread which can scroll the div.

In the no-repro case with the repro case in another tab, the root also acks with CONSUMED_SHOULD_BUBBLE.

This appears to be an issue with the event's coordinates being wrong which causes the compositor to think that the event falls outside of the nonfast scrollable regions. The NFSRs themselves seem fine ("12,12 316x561 | 13,2708 304x91 | 120,3991 197x42" for the non-OOPIF case and "12,12 316x561" for the OOPIF case). However, the coordinates differ between non-OOPIF and OOPIF. For example, with the div scrolled to the top and the mouse over the "All" tab, the point is "46,122" for the non-OOPIF case and "63,169" for the OOPIF case. With the bottom of the image carousel lined up with the bottom of the div and the mouse at the center of the left image, the point is "93,494" for the non-OOPIF case and "128,899" for the OOPIF case. So in the OOPIF case, that point is outside the NFSR, so the compositor thread handles the event.

As for the no-repro case with the repro case in another tab, we can get nonsense values for the event coordinates (e.g. negative y values) which I can't explain yet.

Issue 820232 has been merged into this issue.

It seems that the cross-tab interaction has disappeared (as of r544345 or earlier), i.e. the no-repro case in one tab with the repro case in another tab causing the no-repro case to fail.

Not sure if it's worth bisecting to see what fixed this or not.

wjmaclean@: Yes, please bisect so we can see if the fix can be merged to M66.  (That will also help in understanding why it's fixed.)  Thanks!

Comment 19: Oh, that's not the whole bug, just the weird tab interaction part.  Still, that part may be worth understanding if we can.

mcnee@: Did you say that you had a CL started for the CSS issue?

Yes, I have a fix for the individual repro case. I'm working on a test.

So the weird cross-tab issue is fixed by:

https://chromium-review.googlesource.com/c/chromium/src/+/965016

+fsamuel@, +samans@

We may want to consider merging it as well.

It was merged into M66. The fix should be included in the M66 beta build pushed out tomorrow.

Well that makes things easier! :-)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8961ab574285a3907e22c60eb78eda0d82904e50

commit 8961ab574285a3907e22c60eb78eda0d82904e50
Author: Kevin McNee <mcnee@chromium.org>
Date: Mon Mar 26 23:53:11 2018

OOPIF: Transform point of resent gesture event instead of applying offset.

When bubbling scroll events to ancestor views, we adjust the event's
position by applying the parent's offset. This is incorrect if an OOPIF
is subject to CSS scaling, since the point in the child is scaled. We
now use a transformation function which accounts for scaling.

We were also assuming that the event was being resent to the parent. This
is true for GestureScrollBegin events, but for the remaining events in the
sequence, we may bubble directly to an ancestor, so those events have the
coordinates for the wrong view. We now defer the transformation of the
coordinates to the target view's coordinate space to the
RenderWidgetHostInputEventRouter which knows which view is the target.

Bug: 626020,  817392 
Change-Id: I86331f7bfc5fe7dd9e9032beb16ebb75b579f5b1
Reviewed-on: https://chromium-review.googlesource.com/978647
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545890}
[modify] https://crrev.com/8961ab574285a3907e22c60eb78eda0d82904e50/content/browser/frame_host/cross_process_frame_connector.cc
[modify] https://crrev.com/8961ab574285a3907e22c60eb78eda0d82904e50/content/browser/renderer_host/render_widget_host_input_event_router.cc
[modify] https://crrev.com/8961ab574285a3907e22c60eb78eda0d82904e50/content/browser/renderer_host/render_widget_host_input_event_router.h
[modify] https://crrev.com/8961ab574285a3907e22c60eb78eda0d82904e50/content/browser/site_per_process_hit_test_browsertest.cc
[add] https://crrev.com/8961ab574285a3907e22c60eb78eda0d82904e50/content/test/data/frame_tree/page_with_positioned_scaled_frame.html
[modify] https://crrev.com/8961ab574285a3907e22c60eb78eda0d82904e50/testing/buildbot/filters/viz.content_browsertests.filter

Looks like this is already bisected in C#23, hence removing Needs-Bisect label.

Requesting merge of https://chromium.googlesource.com/chromium/src/+/8961ab574285a3907e22c60eb78eda0d82904e50 to M66.

Impact: If an OOPIF is transformed by CSS scaling, the bubbling of unconsumed scroll events to an ancestor frame may not work correctly.

The CL only affects OOPIF-specific code paths.

Approving merge to M66. Branch:3359

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5857d8c65e779b222549d5794f28941300952f5a

commit 5857d8c65e779b222549d5794f28941300952f5a
Author: Kevin McNee <mcnee@chromium.org>
Date: Thu Mar 29 16:28:25 2018

Merge to M66: OOPIF: Transform point of resent gesture event instead of applying offset.

Note that this CL differs from the original as the representation of
coordinates in WebGestureEvent has changed between M66 and ToT.

OOPIF: Transform point of resent gesture event instead of applying offset.

When bubbling scroll events to ancestor views, we adjust the event's
position by applying the parent's offset. This is incorrect if an OOPIF
is subject to CSS scaling, since the point in the child is scaled. We
now use a transformation function which accounts for scaling.

We were also assuming that the event was being resent to the parent. This
is true for GestureScrollBegin events, but for the remaining events in the
sequence, we may bubble directly to an ancestor, so those events have the
coordinates for the wrong view. We now defer the transformation of the
coordinates to the target view's coordinate space to the
RenderWidgetHostInputEventRouter which knows which view is the target.

(cherry picked from commit 8961ab574285a3907e22c60eb78eda0d82904e50)

Bug: 626020,  817392 
Change-Id: I86331f7bfc5fe7dd9e9032beb16ebb75b579f5b1
Reviewed-on: https://chromium-review.googlesource.com/978647
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#545890}
Reviewed-on: https://chromium-review.googlesource.com/983756
Cr-Commit-Position: refs/branch-heads/3359@{#496}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/5857d8c65e779b222549d5794f28941300952f5a/content/browser/frame_host/cross_process_frame_connector.cc
[modify] https://crrev.com/5857d8c65e779b222549d5794f28941300952f5a/content/browser/renderer_host/render_widget_host_input_event_router.cc
[modify] https://crrev.com/5857d8c65e779b222549d5794f28941300952f5a/content/browser/renderer_host/render_widget_host_input_event_router.h
[modify] https://crrev.com/5857d8c65e779b222549d5794f28941300952f5a/content/browser/site_per_process_hit_test_browsertest.cc
[add] https://crrev.com/5857d8c65e779b222549d5794f28941300952f5a/content/test/data/frame_tree/page_with_positioned_scaled_frame.html
[modify] https://crrev.com/5857d8c65e779b222549d5794f28941300952f5a/testing/buildbot/filters/viz.content_browsertests.filter