Is it just mousewheel scroll that's broken? How about touch scroll, arrow keys, etc.?

I don't have the hardware to test touch, but arrow keys are broken as well.

+bokan, who might have thoughts on this. I'm tracing this now, and it looks like something on the renderer side (MouseWheel and GestureScroll* events are getting targeted correctly AFAICT).

Assigning to Ken.

I can repro on Linux too so likely not OS specific but I don't really have any theories on this. I can help you dig in further if you find where the scroll gets blocked.

One possibility that comes to mind: OOPIFs have no support for ScrollingCoordinator scrollable rects at present ... worth checking?

bokan@: Are you available to help with this? The divergence between the scrolling frames and non-scrolling frames seems to be in ScrollAnimator, I can see the animation getting sent to the compositor for both cases but for the frame that doesn't scroll, ScrollingAnimatorCompositorCoordinator doesn't have any of its notifyAnimation* methods called back from the compositor. I am not very familiar with this code so debugging is slow.

As an aside, it is interesting that if you create 3 or 4 iframes to the same origin, all but one scroll correctly.

Unfortunately I've never poked around in there either. ymalik@ wrote a bunch of code in there but he's no longer working on Chrome. +skobes@ who should be quite familiar.

Looks like something in the cc animation machinery.

re#7: Unfortunately, I'm not familiar with ScrollAnimator code as well.
kenrb@, can you check that player gets attached to a layer for all iframes? 
(In ScrollAnimatorCompositorCoordinator::reattachCompositorPlayerIfNeeded)

I think I have a rough diagnosis, with some debugging help from ajuma@ this afternoon.

Note that with OOPIFs, every local frame root has its own compositor (plus LayerTreeHost, LayerTree, etc), and in particular has its own ScrollAnimatorCompositorCoordinator. This includes independent OOPIFs that are on the same frame tree and in the same process as each other.

In reattachCompositorPlayerIfNeeded(), ScrollAnimatorCompositorCoordinator attaches its AnimationPlayer to a CompositorAnimationTimeline. The timeline is owned by ScrollingCoordinator, which is owned by Page. So in a page with multiple OOPIFs, this means a single CompositorAnimationTimeline will have multiple AnimationPlayers getting attached to it. It looks like the problem scrolling comes from the fact that the LayerTree associated with the AnimationPlayer (which it got from the Timeline) isn't the same as the LayerTree for the Frame's compositor, where the element was registered.

This looks like a pretty clear bug, although it isn't clear to me why scrolling OOPIFs *normally* works, and even works for some of the sibling OOPIFs while breaking for another. We know that ScrollingCoordinator is a problem for OOPIFs (there are some TODOs in the code), but I hadn't caught this interaction before. I won't be able to start trying to figure out a fix for this until next week. Any assistance from experts in this area would be appreciated.

Possibly related to  issue 680158 ?

Also, I'm tentatively marking this as a blocker for --isolate-extensions, though we may revisit.  (I don't know if we're aware of any extensions this affects.)  Can you post an update with your findings and whether you think we can get a fix merged to M56?

ScrollingCoordinator being per-Page seems to be causing all these OOPIF issues, I think it needs to be split up. The baked-in assumption is that ScrollingCoordinator is 1-1 with Compositors which isn't true anymore.

I have filed issue 680606 to fix the larger issue with ScrollingCoordinator, but I would like to proceed with this bug to attempt a shorter term fix (that potentially could be removed when 680606 is addressed). Changing ownership of ScrollingCoordinator looks like a signficant refactor, and if this bug ends up remaining as an isolate-extensions blocker then having to wait for that would impact shipping schedule.

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

commit 65c7df6e695eb4435ccf5485498b34fd1629f898
Author: kenrb <kenrb@chromium.org>
Date: Fri Jan 20 02:04:02 2017

Give OOPIF FrameViews their own scroll animation timelines and hosts

OOPIFs need independent scroll animation timelines and hosts, because
they have separate compositors. Ultimately we need to associate a
ScrollingCoordinator which each local frame root, but until that work
is done this CL resolves some known scrolling problems in
--site-per-process mode.

BUG= 675695 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2631853002
Cr-Commit-Position: refs/heads/master@{#444947}

[add] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/LayoutTests/http/tests/misc/resources/cross-origin-subframe-for-scrolling.html
[add] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/LayoutTests/http/tests/misc/scroll-cross-origin-iframes-expected.txt
[add] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/LayoutTests/http/tests/misc/scroll-cross-origin-iframes.html
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/frame/FrameView.h
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/frame/VisualViewport.cpp
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/page/Page.cpp
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/page/Page.h
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinator.cpp
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinator.h
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/web/WebPagePopupImpl.cpp
[modify] https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898/third_party/WebKit/Source/web/WebViewImpl.cpp

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

commit 551b36390e5a7e8ce6441a62f4bc458fe3b420b8
Author: kenrb <kenrb@chromium.org>
Date: Mon Jan 23 17:23:49 2017

Improve cross-origin-subframe-for-scrolling layout test

The layout test that landed in revision 444947 has some style issues.
This CL addresses them.

BUG= 675695 

Review-Url: https://codereview.chromium.org/2642723009
Cr-Commit-Position: refs/heads/master@{#445396}

[modify] https://crrev.com/551b36390e5a7e8ce6441a62f4bc458fe3b420b8/third_party/WebKit/LayoutTests/http/tests/misc/resources/cross-origin-subframe-for-scrolling.html
[delete] https://crrev.com/b7309482de559eef7acab55c852dd4a29f6e298d/third_party/WebKit/LayoutTests/http/tests/misc/scroll-cross-origin-iframes-expected.txt
[modify] https://crrev.com/551b36390e5a7e8ce6441a62f4bc458fe3b420b8/third_party/WebKit/LayoutTests/http/tests/misc/scroll-cross-origin-iframes.html

This fixes a scrolling bug that could affect some extensions starting in m56, so it might make sense to merge it after it has had a few days to bake. The layout test CL doesn't need to be merged, but the first one does, https://crrev.com/65c7df6e695eb4435ccf5485498b34fd1629f898, as well as a fix to a regression that it caused which is on  issue 683282 , https://chromium.googlesource.com/chromium/src/+/f15f669d84991252dd186c7093b885d7e909fad3.

I think we might be able to get by without this fixed in M56, since we don't have known extensions that it affects yet.  Agreed that we should merge it to M57, though.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please merge your change to M57 branch 2987 ASAP so we can pick it up for this week dev release. Thank you.

govind@: Can I merge both this and the follow-up bug fix, on  issue 683282 , or do I need to separately request merge on that bug?

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

commit 66ec94ea64f65f9d305390b7636bb49ad00b508c
Author: Ken Buchanan <kenrb@chromium.org>
Date: Tue Jan 24 18:27:17 2017

Give OOPIF FrameViews their own scroll animation timelines and hosts

OOPIFs need independent scroll animation timelines and hosts, because
they have separate compositors. Ultimately we need to associate a
ScrollingCoordinator which each local frame root, but until that work
is done this CL resolves some known scrolling problems in
--site-per-process mode.

BUG= 675695 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2631853002
Cr-Commit-Position: refs/heads/master@{#444947}
(cherry picked from commit 65c7df6e695eb4435ccf5485498b34fd1629f898)

Review-Url: https://codereview.chromium.org/2654883002 .
Cr-Commit-Position: refs/branch-heads/2987@{#62}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[add] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/LayoutTests/http/tests/misc/resources/cross-origin-subframe-for-scrolling.html
[add] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/LayoutTests/http/tests/misc/scroll-cross-origin-iframes-expected.txt
[add] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/LayoutTests/http/tests/misc/scroll-cross-origin-iframes.html
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/frame/FrameView.h
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/frame/VisualViewport.cpp
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/page/Page.cpp
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/page/Page.h
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinator.cpp
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinator.h
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/web/WebPagePopupImpl.cpp
[modify] https://crrev.com/66ec94ea64f65f9d305390b7636bb49ad00b508c/third_party/WebKit/Source/web/WebViewImpl.cpp