Do you have a repro URL or a JS snippet that we could use to repro this?  Also, if you go to chrome://flags/#site-isolation-trial-opt-out and set it to "Opt-out (not recommended)", do you still see this problem?

There are a couple of issues which might be related and that were fixed recently (issues  823433  and  837639 ), so it might be worth trying your page on Chrome Canary to see if it's fixed there.

Thanks for the report, and yes a repro example would be very useful for us.

#2: It does sound like  issue 837639  but the bug that caused that only landed in M67. If this is a bug from Chrome 66 then it could be something else.

Hi, I am having this issue as well.

I can't directly post an example, as it contains confidential information, and I haven't been able to reproduce the bug in simple examples either (possibly because you can't get cross-origin requests on localhost).

But what is happening is that I am using the jQuery library Fancybox version 2.1.5 to create an iFrame modal pointing to another page on the same domain as the first. This works in all browsers, including Chrome.

However, if my page is included on a third party website in an iFrame, then when our inner iFrame is opened, the content is not rendered. The content can be viewed with the console, it just isn't being painted on screen. Reloading either iFrame does not fix the problem. This iFrame renders correctly in IE/Edge and Firefox.

Interestingly, iFrames which are present on the page on initial page load are rendered correctly.

Screenshots attached.

Deleted: About Chrome.PNG 9.7 KB

	About Chrome.PNG 9.7 KB View Download

Deleted: Invisible iFrame.PNG 5.6 KB

	Invisible iFrame.PNG 5.6 KB View Download

Deleted: Element console.PNG 11.4 KB

	Element console.PNG 11.4 KB View Download

Deleted: Network console.PNG 6.4 KB

	Network console.PNG 6.4 KB View Download

Comment 4: Thanks for the info!  Can you check to see if the problem exists on Chrome Canary when you enable Site Isolation via chrome://flags/#enable-site-per-process?

As per above comments adding Needs-Feedback label. 

here is the example for you to visualize better.

https://jsfiddle.net/valterlogan/g1utdthm/17/

Thanks everyone for your effort.

Hope you can solve this

Valter Logan

Thank you for providing more feedback. Adding the requester to the cc list.

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

That is very helpful, thanks you.

Confirmed on Canary, I'm looking into it.

Confirmed the issue on Mac/68.0.3425.0 Canary with site-per-process.  The issue went away after disabling site-per-process.

Thanks for the repro!  I can also confirm the issue on Windows M66 and M68, and on ChromeOS 68.0.3471.0.  Strangely, I'm not seeing it on ChromeOS 66.0.3359.137, where the innermost iframe paints even when its parent is scrolled down before clicking the "Open Modal" button.

Anyway, glad Ken is looking into it!  I'll tentatively mark this as a launch blocker while we figure out how wide the impact is and what it takes to fix.  Hopefully we can get a fix merged into M67.

I don't know why you wouldn't be able to reproduce on ChromeOS stable. It is an OOPIF frame throttling bug, so it has been around for a while.

I suspect the intersection code isn't properly accounting for fixed position elements.

If change is ready to be merged by 4:00 PM PT Monday (05/14), then we can take it in for next week beta. Thank you.

I temporary use Chrome dialog element, for my Chrome v66 users, till bug fixed.

Update the jsfiddle for you including this patch.

https://jsfiddle.net/valterlogan/g1utdthm/17/

Thanks for your amazing effort.
Have a nice day.

sorry wrong jsfiddle

here the correct one.

https://jsfiddle.net/valterlogan/g1utdthm/37/

+bokan, pdr, skobes

This looks to me like an interaction between OOPIFs and root layer scrolling, and it is probably faster if I loop in experts.

IntersectionObserver determines when to throttle a RemoteFrame using MapToVisualRectInAncestorSpace. This seems to not do the right thing when we have a fixed position OOPIF that is within an OOPIF, applying the local frame root's scroll offset and thinking it is off screen.

Commenting out the first half of this condition fixes the problem, although this is obviously not correct in general:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_box.cc?l=2559&rcl=eb888830d2c8c283c1e4b58227d2b3a1b25ec660

Any ideas?

I bet I know this bug. I just fixed nearly the same bug in composited layer mapping in https://chromium-review.googlesource.com/c/chromium/src/+/1047193

Basically, we should not use MapToVisualRectInAncestorSpace to map to the LayoutView, and then apply the LayoutView's scroll offset. We cannot do this because the LayoutView's scroll offset only applies to non-fixed descendants. The fix is to use MapToVisualRectInAncestorSpace(nullptr) which maps through the LayoutView.

Do you know if this bug is due to RemoteFrameView::UpdateViewportIntersectionsForSubtree? If so, maybe I could take it.

No, UpdateViewportIntersectionsForSubtree is fine. FrameViews use ElementVisibilityObserver to determine when they should throttle, which wraps the IntersectionObserver machinery.

When I originally plumbed IntersectionObserver for OOPIFs (r443559), it did call MapToVisualRectInAncestorSpace(nullptr) to implicitly get the viewport intersection. It looks like a lot of that code has been refactored for RLS though, so possibly fixed position elements in OOPIFs were broken in the course of that.

I have a CL in progress, just trying to get a layout test working.
https://chromium-review.googlesource.com/c/chromium/src/+/982154

Sorry, that was the wrong link.
https://chromium-review.googlesource.com/c/chromium/src/+/1053840

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

commit f9673ee39996a1aba3a048ba92de6660fa218240
Author: Ken Buchanan <kenrb@chromium.org>
Date: Fri May 11 18:33:39 2018

IntersectionGeometry correctly clip fixed position elements in OOPIFs

IntersectionGeometry::ClipToRoot() incorrectly clips elements with
position:fixed when the element is in an iframe and root layer
scrolling is enabled.

This patch corrects the problem by mapping the intersection_rect_ all
the way to the out-of-process root viewport.

Bug:  840821 
Change-Id: Ia418f3da3950b6ed29a0ecd85601c2cd358456fe
Reviewed-on: https://chromium-review.googlesource.com/1053840
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Stefan Zager <szager@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557954}
[add] https://crrev.com/f9673ee39996a1aba3a048ba92de6660fa218240/third_party/WebKit/LayoutTests/http/tests/intersection-observer/cross-origin-iframe-with-fixed-position-element.html
[add] https://crrev.com/f9673ee39996a1aba3a048ba92de6660fa218240/third_party/WebKit/LayoutTests/http/tests/intersection-observer/resources/iframe-with-fixed-position-element.html
[modify] https://crrev.com/f9673ee39996a1aba3a048ba92de6660fa218240/third_party/blink/renderer/core/layout/intersection_geometry.cc

I'd appreciate if anybody experiencing problems with this bug could test against the next Canary version and let me know if it is resolved. Locally, the fiddle in comment #7 works correctly with that patch applied.

Thanks Ken!  If it still looks good on Monday (stability, verification, etc), then we can request merge to M67.

The NextAction date has arrived: 2018-05-14

The patch from comment 22 is on Canary now, and the comment 7 fiddle looks to be fixed.

If anyone can still see any related issues that still reproduce on Canary then please let me know.

Requesting merge for r557954 to M67.

This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Approving merge for r557954 to M67 branch 3396 based on comment #24 and #27. 

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

commit 88391b75af91e81511dd25ae802716dc8628a812
Author: Ken Buchanan <kenrb@chromium.org>
Date: Mon May 14 17:13:20 2018

IntersectionGeometry correctly clip fixed position elements in OOPIFs

IntersectionGeometry::ClipToRoot() incorrectly clips elements with
position:fixed when the element is in an iframe and root layer
scrolling is enabled.

This patch corrects the problem by mapping the intersection_rect_ all
the way to the out-of-process root viewport.

Bug:  840821 
Change-Id: Ia418f3da3950b6ed29a0ecd85601c2cd358456fe
Reviewed-on: https://chromium-review.googlesource.com/1053840
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Stefan Zager <szager@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#557954}(cherry picked from commit f9673ee39996a1aba3a048ba92de6660fa218240)
Reviewed-on: https://chromium-review.googlesource.com/1057768
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#590}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[add] https://crrev.com/88391b75af91e81511dd25ae802716dc8628a812/third_party/WebKit/LayoutTests/http/tests/intersection-observer/cross-origin-iframe-with-fixed-position-element.html
[add] https://crrev.com/88391b75af91e81511dd25ae802716dc8628a812/third_party/WebKit/LayoutTests/http/tests/intersection-observer/resources/iframe-with-fixed-position-element.html
[modify] https://crrev.com/88391b75af91e81511dd25ae802716dc8628a812/third_party/blink/renderer/core/layout/intersection_geometry.cc

Hi everybody. Great Job. Version M67 working fine. Thanks for everything.