Bugzilla

TYLin noticed today (and I spun off bug 1927229 on this) that the viewport-unit-resolution changes (to the expected value, I think?) if you make tweaks to the print settings, e.g. click the checkbox for "print backgrounds" once or twice.

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](https://bugzilla.mozilla.org/attachment.cgi?id=9335944) 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.)

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](https://bugzilla.mozilla.org/attachment.cgi?id=9335944) 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.)