It’s not just the print preview though. If you print it it’s also blank.

Able to reproduce this issue on reported version 67.0.3362.0 and on latest stable 65.0.3325.186 using Mac 10.13.3, Ubuntu 14.04 and Windows 10.

Good Build: 65.0.3302.0
Bad Build: 65.0.3303.0

You are probably looking for a change made after 526111 (known good), but no later than 526112 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/35cc2b256f2598350915742eefcc505ab902b636..1508f4a32a3fb19d6e3599acc0bcc817ebe6c5be

Reviewed-on: https://chromium-review.googlesource.com/843010

@erikchen: Please confirm the issue and help in re-assigning if it is not related to your change. Adding RB-Stable as this is recent regression. Please change if not the case.

Thanks!

This is a behavior change, but I think it's expected. In the example, the printFrame has attribute: "display:none". Changing that to "display:block" fixes the problem. Can you clarify why you expect a display:none printFrame to still be printable?

I don't think this should block the M-65 rollout, regardless. If this is a bug, we should merge a fix to M-66.

Its a nice javascript solution for printing elements off the page without
having to redirect the user to another page or having this dynamic iframe
show up visible in the screen.  If it works by changing it to block and
then positioning it off screen then I guess that would be sufficient for me

I see. The previous behavior [being able to print the contents of display:none iframes] was I believe not intended. thestig@ to confirm.

The intent is a javascript solution for printing elements on a page.  But it looks like just positioning the dynamic iframe off the screen absolutely works.  The iframe was never meant to be visible to users, so display:none worked.  But since positioning it away also works and seems to behave as I want in all other browsers I think thats good enough for at least me.

Thanks. Closing this bug.

It seems there is a lot of content which expects window.print
on a display:none iframe to work. Re-opening this bug to look further.

Hi, I have a customer experiencing this issue. He is using Google Slides document and when doing a print preview, he is getting a blank preview of the slide. He is using chrome browser 64.0.32.82.186 on macOS and also reproducible on canary version 67.0.3368.0.

Comment 13: Can you open a new bug? The problem described here started in Chrome 65, so if the customer is seeing the issue in Chrome 64 it is likely something different.

Just wanted to add this video to help reference what this bug is. Print view is blank and also prints blank page. Thanks.

Deleted: BadPrinting.mp4 3.7 MB

	BadPrinting.mp4 3.7 MB View Download

I'm not a CSS export, so I took the bug reporter's repro case and checked what other browsers do. Both Firefox and Safari prints the text, so I would suggest we do the same.

Edge also prints it.  This is why I opened the issue in the first place.
No other browser prints emptiness on a display:none; iframe

 Issue 819644  has been merged into this issue.

Erik, how much work do you think it will take to fix this?

Also, s/CSS export/CSS expert/ in comment 16.

I’m not on the chromium tram but the workaround I used was to absolutely
position my iframe offscreen. It prints fine when you do that

The NextAction date has arrived: 2018-03-15

 Issue 820942  has been merged into this issue.

+eae@ (layout expert)

Here is my thoughts: 
Erik's change was trying to clarify the spec. No rendering of 'display:none' should probably be the correct behavior. The way to make OP's problem go away is to use a correct css like "

<style media="screen">
  .printOnly{ display: none; }
</style> 
<style media="print">
  .printOnly{ display: block !important; }
</style>
"

However, many legacy websites still rely on this 'trick' to print even the webkit's side change broke a lot of test (https://bugs.webkit.org/show_bug.cgi?id=107236). So my suggestion is to revert to previous behavior if possible. 

> So my suggestion is to revert to previous behavior if possible. 

I don't feel comfortable reverting this behavior for M-65 [stable channel], which is being re-spun shortly. The possibility that reverting will cause something worse to break is too high. 

I'm currently investigating to see if we can add a workaround to M-66.

It may be possible to render these frames only when printing.  There are already a number of special cases in layout code for printing (see callers of Document::Printing).

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

commit cf1960fc5c3a6e81b9d1325328e828d2bb01179a
Author: erikchen <erikchen@chromium.org>
Date: Fri Mar 16 17:04:57 2018

Allow display:none iframes to have children during printing.

Although it is not spec compliant, many websites intentionally call
Window.print() on display:none iframes.

Bug:  819327 
Change-Id: I02c2b8c9dad0cb6c8c4601c6104986aceb469bba
Reviewed-on: https://chromium-review.googlesource.com/964610
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543734}
[modify] https://crrev.com/cf1960fc5c3a6e81b9d1325328e828d2bb01179a/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/cf1960fc5c3a6e81b9d1325328e828d2bb01179a/third_party/WebKit/Source/core/dom/Document.h
[modify] https://crrev.com/cf1960fc5c3a6e81b9d1325328e828d2bb01179a/third_party/WebKit/Source/core/exported/WebFrameTest.cpp
[modify] https://crrev.com/cf1960fc5c3a6e81b9d1325328e828d2bb01179a/third_party/WebKit/Source/core/layout/LayoutView.cpp

I think a spec bug/PR should be logged against the HTML spec, to allow this.

I added a comment to https://github.com/whatwg/html/issues/1813

This bug requires manual review: M66 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), josafat@(ChromeOS), abdulsyed@(Desktop)

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

Agreed.

Approved. Branch:3359

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

commit 144e6873d7cd5e3a5cde6678e76533b81cf35635
Author: erikchen <erikchen@chromium.org>
Date: Thu Mar 22 20:38:37 2018

[Merge to 3359] Allow display:none iframes to have children during printing.

Although it is not spec compliant, many websites intentionally call
Window.print() on display:none iframes.

Bug:  819327 
Change-Id: I02c2b8c9dad0cb6c8c4601c6104986aceb469bba
Reviewed-on: https://chromium-review.googlesource.com/964610
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#543734}(cherry picked from commit cf1960fc5c3a6e81b9d1325328e828d2bb01179a)
Reviewed-on: https://chromium-review.googlesource.com/976442
Reviewed-by: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#385}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/144e6873d7cd5e3a5cde6678e76533b81cf35635/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/144e6873d7cd5e3a5cde6678e76533b81cf35635/third_party/WebKit/Source/core/dom/Document.h
[modify] https://crrev.com/144e6873d7cd5e3a5cde6678e76533b81cf35635/third_party/WebKit/Source/core/exported/WebFrameTest.cpp
[modify] https://crrev.com/144e6873d7cd5e3a5cde6678e76533b81cf35635/third_party/WebKit/Source/core/layout/LayoutView.cpp

Can anyone give an ETA on when this fix will be in production? 

When M-66 is released, which is about 6 weeks away.

 Issue 827159  has been merged into this issue.

attaching another example.  In this case the content is specifically "display:none" just for "screen" and definitely should have the content printed in print media.

Deleted: iframe-print-test.html 623 bytes

iframe-print-test.html 623 bytes View Download

for anyone looking for a workaround...  It still prints the content if you use "visibility: hidden" and then change the width and height to 0.

 Issue 829248  has been merged into this issue.