Open Bug 1807985 Opened 1 year ago Updated 9 months ago

Add graceful fallback if @page size has zero or negative area for content, after margins are taken into consideration

Categories

(Core :: Printing: Output, defect)

defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(6 files)

https://w3c.github.io/csswg-drafts/css-page-3/#valdef-page-size-length says that negative page sizes are invalid.

It's interesting that zero is allowed there; obviously we can't print anything to a zero-sized page. But also, beyond that: positive size pages are just as problematic if the (default or author-specified) margins are large enough to consume all of the usable page area.

Chrome seems to handle this gracefully by falling back to the system default page-size, or something like that, if the page content area is sufficiently close to zero in either axis.

Specifically:
(1) With zero margins, then the smallest length they'll accept (on my system, to 4 decimal places of precision) is size: 0.0105in. I can provide that as a page size and get an extremely small print-preview result, but e.g. size 0.0104in seems to be ignored and give me US Letter preview. Presumably that's due to a fixed-point representation like nscoord that rounds down to zero for sufficiently small lengths.

(2) With nonzero margins -- e.g. the defaults or with explicit margin: 2in -- Chrome has the same graceful fallback. margin: 2in; size: 4.0105in does produce a tiny page, but if I reduce the size very slightly to 4.0104in then they fall back to US Letter.

Firefox instead produces a bunch of blank pages, which doesn't seem particularly useful.

Perhaps we should implement a similar graceful fallback (at used-value time, not necessarily at parse time) if we can tell that the content area has literally zero area in some axis?

(This is kinda equivalent to testcase 3 but I'm just providing it in case my local Chrome's 0.0105 threshold happens to be fiddly/device-specific.)

Here's the results of these testcases, in Firefox vs. Chrome. Note that in Firefox I chose "scale: 100%" instead of "fit to page content" (doesn't matter much except that it makes content easier to see when it does show up, on extremely small pages)

Testcase   Firefox                       Chrome
1          1 blank page                  Fallback (1 US-Letter page)
2          33 blank pages                Fallback (1 US-Letter page)
3          33 blank pages                20 blank pages
4          4 pages w/ dot of content     3 pages w/ dot of content
5          1 page, css margins ignored?  Fallback (1 US-Letter page)
6          4 pages w/ dot of content     3 pages w/ dot of content

Notes/analysis:
(A) Firefox and Chrome agree on the cases where the page size is small but clearly nonzero (testcases 3, 4, and 6).
(B) Chrome uses a fallback size for all cases where the page content area is zero-sized (or is sufficiently small to be equivalent to zero in their engine, as in testcase 2).

Also, less importantly:
(C) Firefox seems to have a lower threshold (in terms of inches) for what size will round down to zero (which is why we treat testcases 1-2 differently whereas Chrome treats them the same).
(D) At least with the save-to-PDF print backend (the only print target I have configured right now), Chrome renders the tiny pages as being virtual pieces of paper of the specified small-size, whereas Firefox renders the tiny pages as occupying the top-left corner of a full-sized (user-configurable) virtual sheet of paper. That behavior-difference is a known issue and is tracked in bug 1793220; it's not important for the purposes of this bug here. Though it might mean that this bug here will become more important once we fix bug 1793220, since then we might start showing e.g. no-paper-at-all for testcase 1 here.

See Also: → 1793220
Duplicate of this bug: 1838732

Apparently there are in-the-wild sites that specify bogus tiny page sizes, leaving zero space for page content, which are effectively depending on the browser having this graceful fallback. :-/

See https://github.com/webcompat/web-bugs/issues/117996 about https://www.theaa.com/ (the UK Automobile Association, "the UK's largest motoring organisation" per https://www.theaa.com/about-us)

Converting this to a defect since it's now known to trigger actual in-the-wild issues.

Severity: -- → S3
Type: task → defect
Blocks: 521204
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: