Adding a couple more people. Could there be a bug in surface compositing here? Nothing about the embedded surface should be changing, so I can't think of an obvious reason why it would be flickering.

creis, does it also repro on stable or is this a regression?

(I haven't been able to repro this on my Macbook Pro, and don't have a Pixel handy, so I have yet to see this happening.)

James or Ken, can we come back to this?  Darin points out it's still occurring on TechCrunch articles, and I can confirm it on ChromeOS Dev 60.0.3112.0 on a high DPI screen but not on my non-high DPI Windows Canary.

Do you have a video of this?

Does it have to be TDI mode? Or will --site-per-process also trigger this?

#4: I've attached a video.  Watch the blue ad on the right after about 3 seconds.

#5: --site-per-process also triggers it.

Deleted: Jun 5 2017 2-21 PM.webm 6.4 MB

	Jun 5 2017 2-21 PM.webm 6.4 MB View Download

fsamuel@ has suggested that this could be the result of SurfaceID collisions, which I gather might have been known about as a potential issue already. We need to set up a ChromeOS build to test that, since we haven't been able to repro reliably on a non-ChromeOS system.

I think we've seen it on Win10 Dell XPS 13 Canary as well, if that helps.  I don't have one at the moment to test on, though.

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

commit 6ef29daef4aa32b5c744c645891ac4595bc4d073
Author: kenrb <kenrb@chromium.org>
Date: Fri Jun 09 22:16:21 2017

Prevent CompositingHelper from prematurely Satisfying Surface reference

When ChildFrameCompositingHelper::OnSetSurface receives a reference to
a new Surface, it creates a SurfaceLayer and then sends a
FrameHostMsg_SatisfySequence message to the browser to release a
temporary reference that was keeping the Surface alive in the meantime.

The SurfaceLayer creates a new reference to the Surface by sending a
FrameHostMsg_RequireSurface message, but this doesn't happen until
the SurfaceLayer is attached to the layer tree, which is not until the
next BeginMainFrame. Therefore the SurfaceManager was seeing the only
reference to the Surface satisfied before receiving another Require on
it, and this was causing OOPIF flickering during scrolling.

This CL delays when ChildFrameCompositorFrame sends the Satisfy
message, caching the SurfaceSequence until after the SurfaceLayer is
attached to the layer tree.

BUG= 701175 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/6ef29daef4aa32b5c744c645891ac4595bc4d073/content/browser/frame_host/render_widget_host_view_child_frame_browsertest.cc
[modify] https://crrev.com/6ef29daef4aa32b5c744c645891ac4595bc4d073/content/renderer/child_frame_compositing_helper.cc

Running ChromeOS on Linux ToT, which I had found to be a reliable repro scenario last week, this looks fixed. If we wait until that patch makes it into a ChromeOS dev spin then it should be possible to get more general verification.

Does the underlying cause also make embedded YouTube videos flicker while scrolling too? Wondering if I should open a separate issue for that or not.

creis@,
Tested this issue on Windows 10 High DPI device with chrome#61.0.3128.0 & reported version-58.0.3029.12 as per the steps mentioned in comment#0 & comment#6.

Observed no flickering while scrolling page on slashdot.org after loading all ads on the page.

Note: 
Enabled below 2 flags before checking the issue.
1.Top Document Isolation
2.site-per-process

Please find the attached screencast for reference & confirm the issue & fix for the same.
Thanks.

#11: Regarding Youtube videos, it would be the same thing if the video is being created by an extension, or if you are running Chrome with any special flags that create out-of-process iframes, such as --site-per-process. Otherwise it is a different bug. If it is a normal Youtube embedding on a web page and you are running with no flags, then please file a new bug.

#12: Thanks for checking. I'd like confirmation on a ChromeOS device that has the patch, though, since that was where we had the most reliable reproductions.

#12/#14: I have just verified the fix on ChromeOS Dev 61.0.3129.0.  OOPIF ads flickered when scrolling before applying the update, and they no longer flicker after the update.  Thanks!  (Note: for reproing the bug on earlier versions, it helps to scroll by small amounts up and down while the ad stays visible on the page, so that you can watch it flicker.)

#11: I did see YouTube videos show a similar flicker when either Top Document Isolation mode is enabled or with --site-per-process.  That flicker no longer exists in 61.0.3129.0, so hopefully that bug is fixed as well.  If you still see it, I agree with Ken that filing a separate bug makes sense.