Affected versions

• 82.0a1 (2020-09-14)

Affected platforms

• Windows 7

Steps to reproduce

1. Launch Firefox
2. Make sure print.tab_modal.enabled is set on true
3. Open any page
4. Expand More settings and select Print headers and footers
5. Change to Landscape mode
6. Print to paper

Expected result

• The footer is not cut off

Actual result

• The footer is cut off

Regression range

• First bad: b32cb06ef2aeaa939af0484498fcbfd74db05790
• Last good: 24648c48a49cc229f8839d19c22fb2626f767c82
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=24648c48a49cc229f8839d19c22fb2626f767c82&tochange=b32cb06ef2aeaa939af0484498fcbfd74db05790
• Note that, the "good" builds show no footer at all, so the footer was already broken.

Additional notes

• Reproducible with A4, Default margins, both with Fit to page or scale set to 100
• Not reproducible with Save to pdf option

Suggested severity

• S3 since affects only Win 7

Anca, have you ever tested on various printers? I guess it happened on a single printer and it's a printer driver specific issue. But if it happens on multiple printers the issue is more severe than S3 (given that the number of our users on Window 7)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

Anca, have you ever tested on various printers? I guess it happened on a single printer and it's a printer driver specific issue. But if it happens on multiple printers the issue is more severe than S3 (given that the number of our users on Window 7)

• I've reproduced this issue with Kyocera ECOSYS P2135dn;
• Today, cornel.ionceI checked with HP MFP M28, Windows 7, Nightly 82.0a1 (2020-09-14) and the footer had NO issue, was displayed as expected.

Thank you, Anca!

Anca, can you retest Nightly to see if this still reproduces now that the frontend no longer tries to reuse settings objects.

(In reply to Jonathan Watt [:jwatt] from comment #4)

Anca, can you retest Nightly to see if this still reproduces now that the frontend no longer tries to reuse settings objects.

I can still reproduce this issue with 83.0a1 (2020-09-30) and 82.0b5 on Windows 7 with Kyocera ECOSYS P2135dn; sorry for my late response, I was out of office, and the access to this particular printer is limited.

Thanks. I wonder if the print driver is lying about its unwritable margins. That would be worrying.

Bob, any thoughts on this?

(In reply to Jonathan Watt [:jwatt] from comment #6)

Thanks. I wonder if the print driver is lying about its unwritable margins. That would be worrying.

Bob, any thoughts on this?

I wonder if the issue is that we're not allowing for orientation in the unwritable margins.
Because we cache them for what the printer gives us in the standard "portrait" orientation, are those still correct for "landscape"?
I guess it's possible other settings might affect unwritable margins as well.

Assuming this is the issue, this is the problem of having unwritable margins on nsIPaper.
They are not a property of the paper, they are a property of the printer with certain settings applied (including the paper type).
So if we want to cache them, I guess we would need to key on that combination.

(I put "portrait" and "landscape" in quotes, because confusingly there are paper sizes on windows (e.g. DMPAPER_A4_ROTATED) where the width is greater than the height, so the "portrait" configuration actually gives what you would normally consider a landscape layout.)

Anca: what is saved in the prefs for unwritable margins, for that printer?

(In reply to Bob Owen (:bobowen) from comment #7)
...

Assuming this is the issue, this is the problem of having unwritable margins on nsIPaper.
They are not a property of the paper, they are a property of the printer with certain settings applied (including the paper type).
So if we want to cache them, I guess we would need to key on that combination.

Having said that (again if this is the issue) then we can probably just allow for the orientation.
I've also just noticed that this is win7 only, which makes that theory less likely.

(In reply to Bob Owen (:bobowen) from comment #8)

Anca: what is saved in the prefs for unwritable margins, for that printer?

-1 is set as default unwritable margins, but changing them to 0 or 1 doesn't seem to make any difference

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #10)

(In reply to Bob Owen (:bobowen) from comment #8)

Anca: what is saved in the prefs for unwritable margins, for that printer?

-1 is set as default unwritable margins, but changing them to 0 or 1 doesn't seem to make any difference

I'm guessing that's the print.print_unwriteable_margin_* ones.
There should be printer specific ones as well, something like print.printer_Kyocera*.print_unwriteable_margin_*

(In reply to Bob Owen (:bobowen) from comment #11)

There should be printer specific ones as well, something like print.printer_Kyocera*.print_unwriteable_margin_*

Yes, my misunderstanding above, the print specific unwriteable_margin are:

• print_unwriteable_margin_bottom 14
• print_unwriteable_margin_left 17
• print_unwriteable_margin_right 17
• print_unwriteable_margin_top 14

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #12)

(In reply to Bob Owen (:bobowen) from comment #11)

There should be printer specific ones as well, something like print.printer_Kyocera*.print_unwriteable_margin_*

Yes, my misunderstanding above, the print specific unwriteable_margin are:

• print_unwriteable_margin_bottom 14
• print_unwriteable_margin_left 17
• print_unwriteable_margin_right 17
• print_unwriteable_margin_top 14

Thanks Anca, so it does look like that could be the problem.
My guess is that in landscape orientation the landscape bottom of the page should match the portrait right margin (or it could be left) of 17.
If instead we're using the portrait bottom of 14, we get clipped by 3/100 of an inch (or possibly 6/100 because of the top margin as well).

Assuming that the conclusion in comment 13 is correct, I think this is probably not windows 7 specific and could affect any printer with non-uniform unwritable margins.
I don't know if that changes the priority on this.

I suspect the old code paths are currently always going to the printer and so the unwritable margins are always taking account of orientation as well. We need to make sure any changes bring consistency for old and new code paths.

I have encountered this problem with release 88.0.1 on Windows 10 using a Canon G7020 printer, which I gather from the previous comments is expected. I found a work around that I though might help someone figure out the problem. After selecting desired options in the print dialog, if you scroll to the bottom and click "Print using the system dialog...", and Print from there, the footers print as they should in landscape.