1927229 - Reftest inline-block-slice-7.html changes its layout if you make trivial tweaks to print settings

Status: RESOLVED DUPLICATE of bug 1835108

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Attachment: testcase 1 (inline-block-slice-7.html as of Oct 25 2024)

STR:

1. Load inline-block-slice-7.html as it currently stands (attached as "testcase 1")
2. Ctrl+P to view it in print-preview.
3. In advanced settings, check "print backgrounds" and then uncheck it.

EXPECTED RESULTS:
No change in the layout.

ACTUAL RESULTS:
The layout changes.

TYLin noticed this in bug 1926809 comment 7, and is fixing the test so that our in-tree version stops triggering this inconsistency & intermittently failing due to it.

I'm spinning off this bug to track the inconsistency, which presumably remains.

Comment 1

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Attachment: testcase 2

Here's a reduced testcase -- it looks like this issue happens when we mix @page {size} with viewport units.

With this testcase, the content is shrunk super-tiny when I first load this testcase, and then suddenly it becomes readable when I click/unclick "print backgrounds". (This is with "Scale: fit to page width")

If I print-preview this testcase with "Scale: 100%", then on the initial rendering, the div's right border is clipped, and on the second rendering (after toggling print-backgrounds), the div's right border fits just fine.

The problem is probably that we resolve the viewport-units against the default page-size in the first print-preview-rendering, and then we resolve them against the actual @page size on subsequent renderings.

Comment 2

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Actually, this is probably a dupe of bug 1835108, sort-of. The fact that our layout is unstable is new information, I think, but bug 1835108 tracks the fact that our initial layout produces unexpected results for the vw/vh resolution.