Thanks for the report.  Do you have a sample URL where this is happening?

Not that isn't behind authentication.  Basically these are Excel workbooks,
hosted on SharePoint, being iframed into our portal.  They've been in place
for years and the printing has always worked fine.  Recently it stopped
working on Chrome but continues to work fine on all other major browsers.

mdietterick@ - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

I threw together a quick site with dummy data and files to reproduce the
issue.

Let me know if this helps.

https://wms-content.azurewebsites.net/ChromeTest/ChromePrintBug.html

The iframed content does not display in the print preview or when actually
printing.

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

I haven't verified this yet, but this might be related to site isolation.  Can you try setting chrome://flags/#site-isolation-trial-opt-out to "Opt out" and see if that helps?

Thanks for putting together the repro URL.  Though when I open it, I get a prompt to sign in to SharePoint Online in the iframe, and that iframe shows up properly in print preview.  Any way to open up permissions on the dummy doc in the iframe so it doesn't require signing in?

I looked for some other sample sites that embeds Office online docs, and I found the following repro:

1. Go to http://csreis.github.io/tests/cross-site-iframe.html
2. Open DevTools and execute 
navFrame("https://educationgate-my.sharepoint.com/personal/sam_mcneill_educationgate_school_nz/_layouts/15/guestaccess.aspx?docid=17df8114e248d4c9f81c7eff06710be76&authkey=AdPC1GSrfhkCu0gwlSSDzhQ&e=9c19b1955d804e2c8bf08149d149a227&action=embedview")
An embedded Powerpoint should load.
3. Print.

The embedded Powerpoint doesn't show up in print preview with site isolation enabled on Mac canary 69.0.3464.0.  It does show up with site isolation disabled via the opt-out from #7 (whether or not chrome://flags/#use-pdf-compositor-service-for-print is enabled).

weili@, can you please take a look?  Seems there's a nested frame in the OOPIF which provides actual content - maybe something is wrong with that?

Thanks for the report!  We'll look into it.

In the meantime, I think a workaround is to save the page locally, then open the saved copy and print it.

weili@ or thestig@, could you please take a look or help find an owner?  Thanks!

The sharepoint.com URL has an iframe inside. Loading that page by itself also does not print. It used to.

The behavior in comment 12 only happens after performing the steps in comment 8. Starting the browser and printing the sharepoint.com page right away works.

Looks like this has sth to do with multi-level nested iframes. Will dig into it.

It will be good to get an update of what we understand so far.

sorry for the late update, I was out last week. My initial debugging suggested that somehow we lost embedded iframe content either during paintRecord drawing or during skPicture serialization/deserialization. We would need more time to find and fix the root cause.

More update, I found the cause of missing iframe contents and have a way to fix it. However, somehow the RemoteFrame's frame_rect_'s size seems to be incorrect which causes the slide content to be incomplete. I am still investigating.

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

commit 6b0cfc97ccc2d85e7112cf1b46534c0abdb77fa3
Author: Wei Li <weili@chromium.org>
Date: Wed Aug 08 19:52:25 2018

Composite nested oopifs for printing

When there are nested oopifs, an out-of-process subframe may have
nested out-of-process subframe of its own. In such cases, we
should link custom data field of PaintRecord to its place-holder
SkPicture as well. This CL adds such processing in subframe
printing.

BUG= 853942 

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib81e376839be8bd28258fd92ba22e29da566548d
Reviewed-on: https://chromium-review.googlesource.com/1163829
Commit-Queue: Wei Li <weili@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581669}
[modify] https://crrev.com/6b0cfc97ccc2d85e7112cf1b46534c0abdb77fa3/cc/paint/paint_record.cc
[modify] https://crrev.com/6b0cfc97ccc2d85e7112cf1b46534c0abdb77fa3/cc/paint/paint_record.h
[modify] https://crrev.com/6b0cfc97ccc2d85e7112cf1b46534c0abdb77fa3/printing/pdf_metafile_skia.cc

Unable to reproduce the issue on chrome reported version# 67.0.3396.87 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://wms-content.azurewebsites.net/ChromeTest/ChromePrintBug.html
2) Used Ctrl+P for print preview, able to see iframe on print preview window
Observations: Also tried testing on chrome version# 69.0.3464.0 with the steps mentioned in comment# 8, but unable to reproduce the issue.

@Wei Li: Please find the above mentioned information, attached screencast for your reference and let us know if we missed anything in reproducing the issue and help us in verifying the fix.

Thanks!

Deleted: 853942.mp4 2.0 MB

	853942.mp4 2.0 MB View Download

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

commit 1d345bf424233aa92bde586f508d9fb7c9bd03f9
Author: Wei Li <weili@chromium.org>
Date: Fri Aug 10 02:52:37 2018

Add a test for nested oopif printing

When an out-of-process subframe itself also has out-of-process
subframe(s), we need to be able to embed such contents too. This
CL adds a test to make sure our code works in such cases.

BUG= 853942 

Change-Id: I09d1fab4f10e299d3a7fb7f164bbbcfade3eebb5
Reviewed-on: https://chromium-review.googlesource.com/1166032
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582027}
[modify] https://crrev.com/1d345bf424233aa92bde586f508d9fb7c9bd03f9/printing/BUILD.gn
[modify] https://crrev.com/1d345bf424233aa92bde586f508d9fb7c9bd03f9/printing/pdf_metafile_skia.cc
[modify] https://crrev.com/1d345bf424233aa92bde586f508d9fb7c9bd03f9/printing/pdf_metafile_skia.h
[add] https://crrev.com/1d345bf424233aa92bde586f508d9fb7c9bd03f9/printing/pdf_metafile_skia_unittest.cc

Does r581669 fix this?

Re: #19,#21, no the fix is not complete yet. Now we should be able to see the content but somehow its size is not correct. I still have one more fix to go. I will mark this as fixed when it is done.

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

commit e342abf16bc09a2cd86b927c1f0a192119c1fdee
Author: Wei Li <weili@chromium.org>
Date: Sat Aug 18 19:32:45 2018

Use printing layout correctly for subframes

When an oopif is printed along with its parent, this frame should not
use printing layout. Instead, its size is confined by its parent. Before
this change, ShouldUsePrintingLayout() works correctly in
LocalFrame::SetPrinting() since it also checks |use_printing_layout|
variable. But ShouldUsePrintingLayout() doesn't work correctly during
layout code where it is also called to decide whether printing layout
should be applied for style etc.

This CL fixes ShouldUsePrintingLayout() to return the correct value for
all cases.

BUG= 853942 

Change-Id: I6cad75fd6db59d00d4c07ea8b23dbaf6a4a47afc
Reviewed-on: https://chromium-review.googlesource.com/1175404
Commit-Queue: Wei Li <weili@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584319}
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/exported/local_frame_client_impl.cc
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/exported/local_frame_client_impl.h
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/frame/local_frame.cc
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/frame/local_frame.h
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/frame/local_frame_client.h
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/frame/web_local_frame_impl.cc
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/frame/web_local_frame_impl.h
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/page/print_context.cc
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/page/print_context.h
[modify] https://crrev.com/e342abf16bc09a2cd86b927c1f0a192119c1fdee/third_party/blink/renderer/core/page/print_context_test.cc

I am still trying to add more tests for this. But all the fixes are already in since Canary 70.0.3528.0. OP can verify on their websites, viswa.karala@, you can confirm by following steps in #8. thanks!

 Issue 879044  has been merged into this issue.