1250674 - Don't print header/footer if larger than user defined margins

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Tobias Schneider [:tobytailor]]

Apps like PDF.js and Google docs take control over the entire printing page by setting margin to 0 in CSS @page rules. If these margins are smaller then the space needed to print the header of footer, user content gets overdrawn. We should therefore skip painting footers/headers should in this case. Chrome is behaving the same way. This is one of 2 requested features that keeps Google Docs from printing natively.

Comment 1

[Tobias Schneider [:tobytailor]]

Attachment: Part 1: Don't paint header/footer if larger than user defined margins

First shot.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Can you explain what the difference is between mPD->mReflowMargin and mPageContentMargin?

Also, how do other browsers behave?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to David Baron [:dbaron] ⌚️UTC+8 from comment #2)
> Also, how do other browsers behave?

Er, I guess you sort of answered that for Chrome in comment 0, but it's probably worth checking:
 (1) whether the points where we flip from showing to not showing headers will be equivalent with this patch (under different cases, if there are relevant cases to check)
 (2) perhaps check Edge as well, and maybe Safari

Comment 4

[Tobias Schneider [:tobytailor]]

Chrome is using the same flip points. Safari doesn't seem to support CSS defined page margins at all. Edge behaves like Firefox does without this patch, overdrawing user content. It disables printing of headers/fooders by default tho.

Comment 5

[Tobias Schneider [:tobytailor]]

> Can you explain what the difference is between mPD->mReflowMargin and mPageContentMargin?

mReflowMargin defines the default margins as defined via print.print_margin_* prefs. mPageContentMargin holds the actual, CSS specified margins, which might change individually per page.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8722671 [details] [diff] [review]
Part 1: Don't paint header/footer if larger than user defined margins

OK, r=dbaron

It would be nice to add a patch 2 that renames mReflowMargin to mDefaultPageMargin or something like that, since mReflowMargin seems like a rather confusing/ambiguous name.  (If you're happy with that name, feel free to just land it with r=dbaron.)

Comment 8

[Tobias Schneider [:tobytailor]]

Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8cce3d24c6a7

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3fd66d7ceea8

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3fd66d7ceea8

Comment 11

[Petruta Horea [:phorea], Desktop Test Engineering]

Header/footer is not printed anymore on svg images.
Should this fix apply for this type of files too? 

Samples: https://upload.wikimedia.org/wikipedia/en/c/ce/SVG-logo.svg
https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/410.svg
https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/compuserver_msn_Ford_Focus.svg

Thank you!

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Petruta Horea [:phorea], Desktop QA from comment #11)

Header/footer is not printed anymore on svg images.
Should this fix apply for this type of files too?

All seems to be well here now; I can't reproduce this^ described followup behavior. I'm seeing headers/footers when print-previewing those SVG files (as long as the margins in the print preview dialog are sufficient, just as for any other print-previewed content). And this is as-expected, I think.