Open Bug 1763030 Opened 2 years ago Updated 12 days ago

Firefox disagrees with other browsers on viewport size media queries, with `@page { size: a3 }`

Categories

(Core :: Printing: Output, defect)

defect

Tracking

()

People

(Reporter: dholbert, Unassigned, NeedInfo)

References

Details

Attachments

(2 files)

Attached file testcase 1

STR:

  1. Print-preview the attached testcase, choosing "Paper Size: US Letter" (the default for most users in the US), with portrait orientation and default margins.

EXPECTED RESULTS (based on how other browsers behave at least):
The page should show that the viewport's width is "BIGGER" than 767px.

ACTUAL RESULTS:
The page shows that the viewport's width is "SMALLER" than 767px.

Chrome 101 gives EXPECTED RESULTS (it says "BIGGER").
Firefox Nightly 100 gives ACTUAL RESULTS.
(I'm using Ubuntu 21.10 Linux as my environment for both.)

I've included an element with explicit width:767px on the page, as a measurement reference, though I'm not sure how much faith to put into that element's size with respect to the media query, since I can get Chrome to match us (i.e. render "SMALLER") if I specify custom page margins to make its viewport a bit skinnier (and yet still substantially larger than this 767px-wide element).

Note that the testcase uses @page { size: a3 }, though my STR say to use US Letter as your paper size. I think this is supposed to make us print to a "virtual" a3-sized page and then downscale to fit onto US Letter paper... But that doesn't seem to be what's happening, because if I choose A3 in our print dialog as my actual print output size, then I get EXPECTED RESULTS.

This seems to be causing an actual webcompat issue in bug 1759775; see bug 1759775 comment 10 where there's some CSS that strongly depends on the page viewport being over 767px wide; and there's a @page {size:a3} rule elsewhere in the CSS, which makes things work out in Chrome but not in Firefox, it seems. I can "fix" things in Firefox by severely reducing the margins, and break things in Chrome by increasing the margins; but at the default/reasonable margin range of 0.3-0.5in, Chrome is fine and Firefox is not-fine.

Emily, do you know what might be going on here?

Flags: needinfo?(emcdonough)
Attachment #9270805 - Attachment description: test-767px.html → testcase 1
Severity: -- → S3
See Also: → 1763246
See Also: → 1769161

Toggling Scale (to any option) in the preview seem to fix the issue.

See Also: → 1835108
See Also: → 1853766

(In reply to PointlessOne from comment #2)

Toggling Scale (to any option) in the preview seem to fix the issue.

This happens for me too, yeah -- though "Scale" itself is irrelevant, I think. Really, any change that triggers another reflow (e.g. changing "Pages" from "All" to "Current") causes SMALLER to change to BIGGER. So there's some instability here where we've got the value wrong for the initial print-preview presentation, for some reason.

If I'm using my actual physical printer, I see this happen too (SMALLER changes to BIGGER when nudged via e.g. tweaking the "Pages"), but only if I have margins set to Minimum or None. If I use the "Default" margin settings (combined with my printer's unwriteable margins), then the print preview consistently shows SMALLER regardless of pokes to the page range or adjustments to the scale.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: