1835108 - CSS vh/vw units are incorrect for printed output with `@page {size: ...}`

Status: NEW

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Print-preview the attached testcase.
2. Compare the size of the solid-bordered div to the width of the page content box (whose bounds are shown by the dotted border).

EXPECTED RESULTS:
The solid-bordered div should be nearly half of the width of the page content box, and nearly the full height (per its height: 95vh; width: 40vw styling).

ACTUAL RESULTS:
The solid-bordered div is much taller and wider than it should be. It overflows onto a second page, despite having a height that's less than 100vh.

On my machine, it looks like we're mistakenly resolving the vh and vw units as if our page-box were US Letter. But in fact we have @page { size: 5in 6in } defining our page size.

Chrome gives EXPECTED RESULTS.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 print-previewed with Save As PDF printer in Firefox vs. Chrome

Here's how this looks in Firefox vs. Chrome. As shown here, we seem to be using too large (US-Letter-based) sizes for vw/vh, despite the fact that we don't use that size at all here, which makes this extra-weird.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 print-previewed with physical printer in Firefox vs. Chrome

For completeness, here's how this looks with a physical printer. (Same as previous screenshot, except now we've got a larger sheet of paper that the author-defined page is placed onto.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (a bit simpler)

Here's a somewhat-simpler testcase, with just a single div that should fill its page (with a small author-defined-page-size).

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I'm not convinced we should account for @page, see https://github.com/w3c/csswg-drafts/issues/5437

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

I'm not convinced we should account for @page, see https://github.com/w3c/csswg-drafts/issues/5437

It feels pretty broken in the print-to-PDF case (comment 1), where we're apparently resolving these against some default paper size that we're not actually using for the print-to-PDF output at all.

For @pages that we print to different-sized sheets(comment 2), it's maybe more debatable, though I feel like the Chrome behavior is more intuitive... (where 100vh resolves to the same value as height:100% on the root element, in all the cases I've tested)

Comment 7

[jeremy.leland]

For a real-world example, here is a worksheet I created for my work: https://jeremyleland.github.io/brain/ . It uses a full-height table that is duplicated for a total of 4 tables (two on each side of a double-sided page). This prints correctly in Edge and Chrome, but ends up spilling onto multiple pages in Firefox (thus breaking the 4-on-one-sheet setup). (This was the basis for 1846926).

Comment 10

[Daniel Holbert [:dholbert]]

TYLin noticed today (and I spun off bug 1927229 on this, and then duped it here) that Firefox's viewport-unit lengths end up getting re-resolved if you make tweaks to the print settings, e.g. click the checkbox for "print backgrounds" once or twice. And they end up on the expected value after that re-resolution.

So: whether or not we should account for @page when resolving these units (per comment 4), we apparently do account for it, but not on the first rendering (specifically in print-preview).

(Also: when I proceed to actually print, to e.g. our save-to-PDF backend at least, we end up producing expected-results here -- e.g. testcase 2 produces a single page with a solid border around its content. This is true regardless of whether I've messed with the settings. It's only our initial print-preview rendering that seems to be wrong.)