1763246 - Headers and footers are clipped, with @page { size: a3 }

Status: ASSIGNED

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Print-preview the attached testcase.
2. Choose "Paper Size: US Letter" or "A4" in our print dialog.

ACTUAL RESULTS:
The top-right header is clipped or missing entirely.
The footers are missing entirely.

EXPECTED RESULTS:
No such clipping.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot (loading long bugzilla-hosted URI vs. short file:// URI)

Here's a screenshot, showing two side-by-side attempts at this, to illustrate that this is worse for short URIs since the top-right header (the URI) gets fully-clipped in that case.

Comment 2

[Daniel Holbert [:dholbert]]

Note:

• if you choose A3 as your output paper size, then everything works fine.
• if you choose Tabloid as your output paper size, then things are almost-fine; the footers show up on the bottom, but the right edge of the top-right and lower-right footer get clipped. (This sort of makes sense, since I think Tabloid is taller-and-slightly-skinnier than A3)
• All the other paper sizes seem to be problematic here (since I think they're all smaller than A3)

Comment 3

[Daniel Holbert [:dholbert]]

Running mozregression with the layout.css.page-size.enabled pref manually enabled (to avoid bisecting to the pref-default-enabling commit), I got this regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=61b00062dcdd41077516b098afe63fd49ba44187&tochange=4aee63294f3940bf9b80611a4e6989700a558386

...which is just bug 1647851.

(In "good" builds before that, it looks like we're just ignoring the specified page size, basically, which trivially prevents the clipping issue.)

Comment 4

[Daniel Holbert [:dholbert]]

Note regarding the potential for sites to hit this: twitter bootstrap used to include @page{size:a3} (e.g. as part of the file styles.css in bug 1759775's zipped-up testcase, which declares itself to be "Bootstrap v4.5.3")

However, that seems to have been removed as part of Bootstrap version 5, in this commit:
https://github.com/twbs/bootstrap/commit/473689ce5de5337984c16a9c5dacad328101ffb1#diff-108a57a50d5ebe203f447ef7bf1e5e53826bdb82baab2baa2b41b4158cdd4d09L1133

Comment 5

[Daniel Holbert [:dholbert]]

FWIW, I just ran into this again in the wild (again with @page{size:a3}) at https://sanmateo-ca.county-taxes.com/public/search/gsgx_property_tax

If I print-preview that page (or other pages on that domain, e.g. property-tax receipts/statements), I hit this issue, unless I explicitly choose A3-size paper as my print target in the print-preview dialog.

Comment 6

[Daniel Holbert [:dholbert]]

(I think jwatt is working on this, assigning to him to reflect reality.)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #4)

Note regarding the potential for sites to hit this: twitter bootstrap used to include @page{size:a3} [...]
However, that seems to have been removed as part of Bootstrap version 5, in this commit:

Historical note: the choice of A3 seemed curious, so I chased this back a bit further to see when this was added. It comes from this pull-request/commit:
https://github.com/twbs/bootstrap/pull/25164
https://github.com/twbs/bootstrap/pull/25164/commits/9fa23d33d8e76a69545c9db9e67107a48f68d28d#diff-108a57a50d5ebe203f447ef7bf1e5e53826bdb82baab2baa2b41b4158cdd4d09R886
"Add basic print styles for page and body size to create a semi-consistent print experience across browsers"

It doesn't seem like the choice of A3 was particularly thought-through - it just happened to produce a more consistent print-scale across browsers (those that supported @page) at the time.

Anyway: for the purposes of this bug here, @page { size: a3} is only relevant insomuch as it's a size that's larger than the actual print target that I have available (larger than the size that I choose in the print dropdown per STR). We should be able to repro/test this bug using @page { size: letter } etc. as long as the user-selected print target is something smaller.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (using specified @page { size: letter } -- try to print-preview using A5 or B5 as user-selected paper size)

For completeness, here's a testcase to demonstrate the @page { size: letter } scenario.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing the issue with testcase 2

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Setting Regressed by field after analyzing regression range found by mozregression in comment #3.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1647851

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1647851

Comment 13

[Jim Mathies [:jimm]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

(I think jwatt is working on this, assigning to him to reflect reality.)

Hey jwatt, is this accurate or is this lower priority?