Print PDF does not contain page breaks for content from an iframe
Reported by
dmitriy....@gmail.com,
May 15 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 Example URL: https://jsfiddle.net/j7oxd0v8/12/ Steps to reproduce the problem: 1. Go to https://jsfiddle.net/j7oxd0v8/12/ 2. In print preview dialog select Destination: Save to PDF What is the expected behavior? Generated PDF contains page breaks after each page div. What went wrong? When I put my content along with CSS containing page breaks in an iframe, page breaks are not rendered in resulting PDF. When I extract content from an iframe page breaks are rendered correctly, see https://jsfiddle.net/09cw0tn6/1/ Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 66.0.3359.170 Channel: stable OS Version: OS X 10.13.4 Flash Version:
,
May 16 2018
Thanks for filing the issue! Able to reproduce the issue(...considering URL in point no.1 of C#0 https://jsfiddle.net/j7oxd0v8/12/ page break is seen) on reported chrome version 66.0.3359.170 and on the latest canary 68.0.3431.0 using Mac 10.13.1, Ubuntu 14.04 and Windows 10. As the issue is seen from M60(60.0.3112.0) considering it as Non-Regression and marking it as Untriaged. Note: Tentatively adding component "Internals>Printing", please remove if this isn't apt.
,
May 16 2018
This is something for Blink layout experts to look at. Does the page in question print correctly in any other browser?
,
May 17 2018
Safari doesn't seem to respect page breaks as well (and it can't pick up page size from media query) Firefox can't print it to PDF at all, produces blank page. So Chrome definitely gives the best result, but it would be nice to understand whether ignoring page breaks in an iframe is expected behavior.
,
May 18 2018
,
May 19 2018
The IFRAME in the test is on a line in the outer document. Lines are monolithic, so we don't perform any fragmentation inside. Even if the IFRAME were block-level (display:block), I still don't know if we should fragment it, since an IFRAME is replaced content, and replaced content is generally considered monolithic as well. https://www.w3.org/TR/css-break-3/#possible-breaks |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, May 15 2018