Note: Also tested on Mac - same issue.

Thanks!  It does look like out-of-process iframes could be involved, given the task manager screenshot.  Can you try running Chrome with --force-fieldtrials=SiteIsolationExtensions/Control to see if the issue goes away?

Also, is there an extension we can install to repro this bug, or a simple test case you could attach to the bug?  I don't see the bug in a simple extension that sets up the following hierarchy: https://www.chromium.org embeds extension URL embeds https://csreis.github.io/tests/cross-site-iframe-simple.html (which itself has an iframe).  All iframes seem to render properly.

This might be the same as  issue 638375 . I can check it tomorrow when I'm at the office.

Since we circumvented the issue in production (killed the functionality), I set up a development server where you can see the issue easily. 
Initial set up of the extension is somewhat windy, but shouldn't take more than 5 minutes. Here are instructions:
(1) Install "FI Gamma (Internal)" chrome extension found at https://chrome.google.com/webstore/detail/fi-gamma-internal/ikkcpcmoipofkhnfoaclnhgjaafolmde
- Note: You will be required to give application permissions. You can later revoke them.
(2) Set extension to work with "Dev" server
(a) Open chrome://extensions
(b) Make sure "Developer mode" is checked
(c) Locate "FI Gamma (Internal)"
(d) Open "Options"
(e) Select "Dev" and press "save"
(3) Open new gmail window
You are now using the developer extension against the developer server

To see the iframe bug:
(1) Open gmail
(2) Open FlashIssue editor (Press the "FlashIssue" button and select "goto Editor"
(3) Press the "Preview" button
A "Dialog" will appear which contains an iframe manifesting the issue. 

Feel free to contact me directly on hangout if more data is needed - omri.spector

Thank you for providing more feedback. Adding requester "creis@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thanks for the help reproducing it. I can see the problem with that extension.

It looks like some sort of raster problem. I think this is an out-of-process iframe within an out-of-process iframe (because there is an extension iframe that iframes flashissue.com). Interestingly, the nested iframe is drawing, but an inner same-site iframe is having trouble.

It looks like it initially draws, but then subsequently goes white. I can get the graphics to correctly display but when I cause any damage then I lose the affected compositor tiles.

More info: When running chrome with --force-fieldtrials=SiteIsolationExtensions/Control things work correctly.

+ajuma@

Yes, I also verified that it only happens when out-of-process iframes are present.

Something interesting that lfg@ and I found that might help with a temporary workaround:
The iframe that has paint problems is contained within a div, and the div has its CSS display property toggled between 'none' and 'block' to hide or show the preview pane. If I use devtools to toggle that value directly, everything paints properly. Even after the preview is open and is showing white, if I add display:none to the iframe and then remove it again then it fixes the problem. Potentially a small hack to your code could use that to make the feature work again, until this bug is fixed. Alternatively, removing the transition that brings the div into view might work.

It looks like something in the layout or paint state for the iframe is becoming corrupted while the div is being displayed (there seems to be some sort of opacity transition, which I conjecture might be related). Changing the iframe to display:none destroys its layout object and resets the layout/paint state, so the problem goes away.

If it's related to the opacity transition, I wonder if it has something to do with the optimization that skips painting opacity 0 layers.

#10: That's a good suggestion but it doesn't seem to be the problem. It still repros if PaintLayerPainter::PaintedOutputInvisible() always returns false.

Does it fail at ToT?

#12: Yes, I've been testing on Windows trunk, and just verified on a current sync.

In comment 7 above I mentioned that *sometimes* I could load the frame and have it display correctly, only to have any compositor tile go blank whenever there is damage on it, like mousing over a link or highlighting text. In case anybody else is trying to reproduce, it is worth mentioning that I can only make that happen on a debug build because in release the graphics always go blank right away.

I have a fix for this, will upload for review after I write a test.

The problem ends up being with IntersectionObserver in OOPIFs. In this case, where we have an OOPIF nested within another OOPIF that never changes, the intersection rect with the viewport is not propagating through the OOPIFs properly, and as a result the LocalFrame within the nested OOPIF is throttled. Notably, resizing the browser window fixes the problem because it causes the viewport intersection rects to cascade through the OOPIFs with correct values.

Note comment over on https://bugs.chromium.org/p/chromium/issues/detail?id=637373#c31

Maybe see if that repros with the fix you have?

Hello,

I am also facing the bug with iframe rendering in Chrome 58.0.3029.81 (64-bit) on Linux. Please check the video (https://drive.google.com/file/d/0ByG9lmw9sRzbZzkxb2hEbnBXdGM/view?usp=sharing) for details (it is better to download it, as a preview has a very bad quality).

Credentials for test account on surfly.com:
email: yauhen+chrome@surfly.com
password: chrometest

To reproduce it you need to start a session with test url http://dev.sascargo.com/en/Environment/TestCobrowseAPI.aspx and join the session with Chrome browser. Please also enable "Disable cache" option in developer toolbars.

I also noticed that on the test page (http://dev.sascargo.com/en/Environment/TestCobrowseAPI.aspx) inside the <head> element there is a <link> element:

<link rel="stylesheet" href="/styles/StyleCollection.css" type="text/css">

The content of the file is the following:
@import url("BasicDesign.css");
@import url("HeaderDesign.css");
@import url("NavigationDesign.css");
@import url("FooterDesign.css");
@import url("TextDesign.css");
@import url("SubMenuDesign.css");
@import url("ContentDesign.css");
@import url("Common.css");
@import url("StationFileStyle.css");
@import url("Components/ImageList.css");
@import url("Skins/SasCargo/Grid.SasCargo.css");
@import url("Skins/SasCargo/Calendar.SasCargo.css");
@import url("Skins/SasCargo/ComboBox.SasCargo.css");
@import url("Skins/SasCargo/ToolTip.SasCargo.css");
@import url("Skins/SasCargo/Editor.SasCargo.css");
@import url("Skins/SasCargo/Menu.SasCargo.css");

If I move imports out of the css file directly into the <style> element like this:
<style type="text/css">
@import url("/styles/BasicDesign.css");
@import url("/styles/HeaderDesign.css");
@import url("/styles/NavigationDesign.css");
@import url("/styles/FooterDesign.css");
@import url("/styles/TextDesign.css");
@import url("/styles/SubMenuDesign.css");
@import url("/styles/ContentDesign.css");
@import url("/styles/Common.css");
@import url("/styles/StationFileStyle.css");
@import url("/styles/Components/ImageList.css");
@import url("/styles/Skins/SasCargo/Grid.SasCargo.css");
@import url("/styles/Skins/SasCargo/Calendar.SasCargo.css");
@import url("/styles/Skins/SasCargo/ComboBox.SasCargo.css");
@import url("/styles/Skins/SasCargo/ToolTip.SasCargo.css");
@import url("/styles/Skins/SasCargo/Editor.SasCargo.css");
@import url("/styles/Skins/SasCargo/Menu.SasCargo.css");
</style>

there is no rendering issues.

The website renders properly in all other browsers.

Video: https://drive.google.com/file/d/0ByG9lmw9sRzbZzkxb2hEbnBXdGM/view?usp=sharing

Unlike it is pointed in comment 14, resizing browser has no affect on the iframe. Editing HTML as it is shown in the video has. I think it is a different issue. Should I create a new one?

Re#17: Yes, please create a new issue.

The new issue (https://bugs.chromium.org/p/chromium/issues/detail?id=718358) is created from the comment #16

I can't repro the issue in comment 16 on Canary, but I also don't think it is the same problem in any case. It doesn't look like there are any extensions involved, which means no out-of-process iframes.

It could also be related to frame throttling, though, based on the video.

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

commit 321a171abcca381e3ef72d01996e4ae4dd860212
Author: kenrb <kenrb@chromium.org>
Date: Mon May 08 14:13:32 2017

Propagate viewport intersection across OOPIFs at the correct time

This corrects a couple of issues with how viewport intersection rects
were being sent to OOPIF processes from their parents, which was causing
frame throttling bugs:

1. The update is now triggered from the parent FrameView's
UpdateViewportIntersectionsForSubtree, rather than the RemoteFrameView's
frameRectsChanged. Formerly, this would cause intersection calculations
in a dirty layout tree, and also fail to propagate intersection rect
changes in the case of nested OOPIFs.

2. Viewport intersections are now updated properly when the iframe
is scrolled off of screen. Previously it would return early when an
OOPIF had no viewport intersection, which was wrong.

BUG= 682307 ,  712320 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[add] https://crrev.com/321a171abcca381e3ef72d01996e4ae4dd860212/third_party/WebKit/LayoutTests/http/tests/intersection-observer/cross-origin-iframe-with-nesting.html
[add] https://crrev.com/321a171abcca381e3ef72d01996e4ae4dd860212/third_party/WebKit/LayoutTests/http/tests/intersection-observer/resources/nested-cross-origin-subframe.html
[add] https://crrev.com/321a171abcca381e3ef72d01996e4ae4dd860212/third_party/WebKit/LayoutTests/http/tests/intersection-observer/resources/nesting-cross-origin-subframe.html
[modify] https://crrev.com/321a171abcca381e3ef72d01996e4ae4dd860212/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/321a171abcca381e3ef72d01996e4ae4dd860212/third_party/WebKit/Source/core/frame/RemoteFrameView.cpp
[modify] https://crrev.com/321a171abcca381e3ef72d01996e4ae4dd860212/third_party/WebKit/Source/core/frame/RemoteFrameView.h

This should bake for a bit, but should probably be merged to M-59, since it is known to cause problems for extensions.

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

Please merge this to M59 ASAP. 

I can merge this for Ken.  (Doesn't look like there's any fallout in the crash reports for 60.0.3094.0.)

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

commit c4999457b7f0e7121f4067d9bdf86a93299a8c94
Author: Charles Reis <creis@chromium.org>
Date: Tue May 09 23:05:45 2017

Propagate viewport intersection across OOPIFs at the correct time

This corrects a couple of issues with how viewport intersection rects
were being sent to OOPIF processes from their parents, which was causing
frame throttling bugs:

1. The update is now triggered from the parent FrameView's
UpdateViewportIntersectionsForSubtree, rather than the RemoteFrameView's
frameRectsChanged. Formerly, this would cause intersection calculations
in a dirty layout tree, and also fail to propagate intersection rect
changes in the case of nested OOPIFs.

2. Viewport intersections are now updated properly when the iframe
is scrolled off of screen. Previously it would return early when an
OOPIF had no viewport intersection, which was wrong.

BUG= 682307 ,  712320 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2860903003
Cr-Commit-Position: refs/heads/master@{#469977}
(cherry picked from commit 321a171abcca381e3ef72d01996e4ae4dd860212)

Review-Url: https://codereview.chromium.org/2873083002 .
Cr-Commit-Position: refs/branch-heads/3071@{#489}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[add] https://crrev.com/c4999457b7f0e7121f4067d9bdf86a93299a8c94/third_party/WebKit/LayoutTests/http/tests/intersection-observer/cross-origin-iframe-with-nesting.html
[add] https://crrev.com/c4999457b7f0e7121f4067d9bdf86a93299a8c94/third_party/WebKit/LayoutTests/http/tests/intersection-observer/resources/nested-cross-origin-subframe.html
[add] https://crrev.com/c4999457b7f0e7121f4067d9bdf86a93299a8c94/third_party/WebKit/LayoutTests/http/tests/intersection-observer/resources/nesting-cross-origin-subframe.html
[modify] https://crrev.com/c4999457b7f0e7121f4067d9bdf86a93299a8c94/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/c4999457b7f0e7121f4067d9bdf86a93299a8c94/third_party/WebKit/Source/core/frame/RemoteFrameView.cpp
[modify] https://crrev.com/c4999457b7f0e7121f4067d9bdf86a93299a8c94/third_party/WebKit/Source/core/frame/RemoteFrameView.h