Closed Bug 1722890 Opened 4 years ago Closed 4 years ago

fixed positioned (bottom offset-ed) footer isn't print-ed out

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Version:
Firefox 90
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
93 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- verified
firefox90 --- unaffected
firefox91 --- unaffected
firefox92 --- verified
firefox93 --- verified

People

(Reporter: foysal.mamun.lifo, Assigned: alaskanemily)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

footer_testing.html
5.66 KB, text/html
Details
testcase 2 (further reduced)
469 bytes, text/html
Details
Bug 1722890 Part 1 - Apply page scaling to the clipping rect for page content frames
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
RyanVM
: approval-mozilla-esr91+
Details | Review
Bug 1722890 Part 2 - Add disabled print preview test for scaled content on the edge of the clipping rect
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
RyanVM
: approval-mozilla-esr91+
Details | Review
Attached file footer_testing.html —

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

save to pdf a page where page width is fixed to 965px and fixed positioned footer.

css is :

.footer {
position: fixed;
bottom: 0;
clear: both;
}

and for example body width is
<body style="width: 965px;">

Actual results:

footer is not displayed on save to pdf

Expected results:

footer should be displayed as before version 90

If i set the body width to 700px then footer print perfectly.

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → PDF Viewer
Component: PDF Viewer → Untriaged
Component: Untriaged → Printing: Output
Product: Firefox → Core
Severity: -- → S2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: fixed positioned footer print pdf issue → fixed positioned (bottom offset-ed) footer isn't print-ed out
Flags: needinfo?(emilio)

Mozregression says this was caused by bug 1717703: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0d307662db0f5204ea6286e95e885d8ab12c57e8&tochange=f46839a3cf869168e295850f9fea9f854f2122c8

Emily can you take a look?

Flags: needinfo?(emilio) → needinfo?(emcdonough)
Regressed by: 1717703
Has Regression Range: --- → yes

This reduced testcase reproduces the bug for me, if I print-preview it at a 90% scale factor (using the "Scale" setting in the More Settings print-preview option.)

This bug specifically happens when we are printing at a less-than-100% scale factor. In the original testcase, we were hitting that codepath because of the wide width on the body, which triggers downscaling for the default "shrink to fit page width" option. But you can also trigger this bug more directly by simply choosing a specific <100% scale factor. E.g. with the attached testcase, "Scale: 90%" triggers the issue.

I'm guessing we're messing something up when pruning our display list for items that can be entirely clipped. We must not be taking the scale-down factor into consideration when determining whether the item is visible or not.

Note that the "Footer" text does seem to be positioned at the correct spot; it's just that we incorrectly prune it from our paintable stuff, probably because we think it's outside of the painted area, because we must be making some "filter out any out-of-bounds display items" pruning-pass without taking the Scale into consideration.

If you add an explicit and sufficiently-large height to the footer, then that works around this bug & makes the footer show up, presumably because some of it makes it back into the area that we think is painted.

My guess: we probably need to be scaling pageContentRect (or maybe just its size component?) by pc->GetPageScale() in the new code that bug 1717703 added. (I think this GetPageScale() is the scale that corresponds to this print Scale: [...] factor.)

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

status-firefox90: --- → unaffected
status-firefox91: --- → unaffected
status-firefox92: --- → affected
status-firefox-esr78: --- → unaffected

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

Created attachment 9234328 [details]
testcase 2 (further reduced)

This reduced testcase reproduces the bug for me, if I print-preview it at a 90% scale factor (using the "Scale" setting in the More Settings print-preview option.)

This bug specifically happens when we are printing at a less-than-100% scale factor. In the original testcase, we were hitting that codepath because of the wide width on the body, which triggers downscaling for the default "shrink to fit page width" option. But you can also trigger this bug more directly by simply choosing a specific <100% scale factor. E.g. with the attached testcase, "Scale: 90%" triggers the issue.

I'm guessing we're messing something up when pruning our display list for items that can be entirely clipped. We must not be taking the scale-down factor into consideration when determining whether the item is visible or not.

Yes, I get the footer at 90% scale but other contents are clipped since it has a fixed width (965px).

dholbert was right, the issue was that we were not applying the page scale to the clipping rect for each page content frame. This patch should fix that.

Flags: needinfo?(emcdonough)
Assignee: nobody → emcdonough
Status: NEW → ASSIGNED
See Also: → 1725486
Attachment #9235696 - Attachment description: Bug 1722890 Part 2 - Add print preview test for scaled content on the edge of the clipping rect → Bug 1722890 Part 2 - Add disabled print preview test for scaled content on the edge of the clipping rect
Pushed by emcdonough@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b660fa9270e3 Part 1 - Apply page scaling to the clipping rect for page content frames r=dholbert https://hg.mozilla.org/integration/autoland/rev/c69cd7bad3a9 Part 2 - Add disabled print preview test for scaled content on the edge of the clipping rect r=dholbert

https://hg.mozilla.org/mozilla-central/rev/b660fa9270e3
https://hg.mozilla.org/mozilla-central/rev/c69cd7bad3a9

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox93: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch

Please nominate this for Beta approval when you get a chance.

status-firefox-esr91: --- → unaffected
Flags: needinfo?(emcdonough)
Flags: in-testsuite+

Comment on attachment 9235695 [details]
Bug 1722890 Part 1 - Apply page scaling to the clipping rect for page content frames

Beta/Release Uplift Approval Request

  • User impact if declined: Printing with certain scaling levels will cause clipped content
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Enter print preview with https://bugzilla.mozilla.org/attachment.cgi?id=9234328 and scale output to 90%. The footer box should still be visible.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The change is small and self-contained. It should at worst just not catch all cases of this bug, but I was not able to reproduce any further examples.
  • String changes made/needed:
Flags: needinfo?(emcdonough)
Attachment #9235695 - Flags: approval-mozilla-beta?
Attachment #9235696 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9235695 [details]
Bug 1722890 Part 1 - Apply page scaling to the clipping rect for page content frames

Approved for 92.0b4.

Attachment #9235695 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9235696 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Reproduced the issue on Firefox 92.0a1 (2021-07-29) under macOS 11.5 using the testcase provided in Comment 0.

The issue is fixed on 93.0a1 (2021-08-15) and 92.0b4. Tests were performed on macOS 11.5, Windows 10 and Ubuntu 20.04.

Status: RESOLVED → VERIFIED
status-firefox92: fixed → verified
status-firefox93: fixed → verified
Flags: qe-verify+
Regressions: 1732836

Comment on attachment 9235695 [details]
Bug 1722890 Part 1 - Apply page scaling to the clipping rect for page content frames

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This bug is needed to fix a regression caused by bug 1717703. However, this introduces another regression which must be fixed by also uplifting bug 1732836.
  • User impact if declined: Printing with certain scaling levels will content to be is cut off.
  • Fix Landed on Version: 92
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a relatively small change which has been tested and landed on Nightly/Release for some time, and the known regression will be fixed with 1732836.
  • String or UUID changes made by this patch:
Attachment #9235695 - Flags: approval-mozilla-esr91?
Attachment #9235696 - Flags: approval-mozilla-esr91?

Comment on attachment 9235695 [details]
Bug 1722890 Part 1 - Apply page scaling to the clipping rect for page content frames

Needed for bug 1717703, approved for 91.5esr.

Attachment #9235695 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9235696 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Flags: qe-verify+

Verified that the issue is fixed in Firefox ESR 91.5.0. Tests were performed on macOS 12.0.1, Windows 11 and Ubuntu 20.04.

status-firefox-esr91: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: