Improper number of pages in print mode in case of dynamic content
Reported by
alexande...@gmail.com,
Jan 12 2018
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: 1. Open this codepen https://codepen.io/oxygen90/pen/PEapKm/ in full-screen mode https://s.codepen.io/oxygen90/debug/PEapKm/yoMZEQqQzOyk 2. Press "Ctrl + P" to trigger print mode. What is the expected behavior? Changing div height should cause adding a new page so that it can be printed entirely on two pages. What went wrong? After changing the div height it is still only one page and the div with red border couldn't be printed entirely. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 63.0.3239.132 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 28.0 r0 It looks like browser estimates a desired number of pages by the result of the previous rendering. If you reload a page, press "Ctrl + P" and then set custom page fields or choose another paper format (switch from US Letter to A4 for example) to trigger another `MediaQueryListEvent`, you can see that second page is added.
,
Jan 22 2018
Does the code work correctly in any other browser?
In Chromium, by the time the window.matchMedia('print') listener fires to update the <div> dimensions, the browser's printing code has already calculated the page count.
If you want JS to run before the browser's printing code, try window.onbeforeprint. Chromium has support for onbeforeprint in version 63.
,
Jan 22 2018
,
Mar 12 2018
Mac triage: closing old issue without feedback for >30 days. |
|||
►
Sign in to add a comment |
|||
Comment 1 by krajshree@chromium.org
, Jan 15 2018Labels: Triaged-ET M-65 Needs-Triage-M63 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)