Open Bug 1814236 Opened 2 years ago Updated 1 year ago

If users have a custom print scale saved, we apply it when previewing content with `@page { size ... }`, potentially causing truncation

Categories

(Core :: Printing: Output, defect)

defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

Details

Attachments

(4 files, 1 obsolete file)

Attached file (original version of testcase 1 with a typo, oops) (obsolete) (deleted) —

STR:

  1. Print-preview some trivial page like e.g. https://example.org/
  2. Make sure "More settings..." is expanded so that you can see the "Scale" setting.
  3. Change the scale to some large value, e.g. 150%, and then hit "Cancel"
  4. Load the attached testcase.
  5. Print-preview (or print) the testcase.

ACTUAL RESULTS:
The testcase's content is clipped on the right, and it might extend onto a second page at the bottom.

EXPECTED RESULTS:
No clipping / overflow onto additional pages (by default at least).

The problem is that we're carrying forward the user's saved scale value -- which the user set for content-with-no-particular-page-size -- and we're applying it to precisely-sized content with a specified page size, such that the content overflows the page size that the author set it up specially to fit.

Possibly we should just ignore the saved scale, and maybe even hide the UI to configure it? Or we could show the UI but have it be set to the default value. (And if the user does interact with it, we'd have to decide whether/where to save that customized value, since presumably we'd reset to the default again when the user previews another document with an author-specified page-size...)

(Side note: sorry, the attached testcase says "This div is as large as the virtual piece of paper" which isn't quite true -- I was a bit loose with language there. Really, the div is as large as the virtual page, which we lay out onto a potentially-larger virtual sheet of paper right now, though that's changing in bug 1793220. Regardless, though: in my STR, the 150% scaling causes content to be clipped at the edge of the virtual page; this is true now, and it will continue to be true after bug 1793220 lands.)

Severity: -- → S3
Attached file testcase 1 (deleted) —

oops, I had a typo (width: 4n, should be 4in) in the first version of the testcase, which made it not reproduce the issue.

Here's a corrected version.

Attachment #9315222 - Attachment is obsolete: true
Attachment #9315222 - Attachment description: testcase 1 → (original version of testcase 1 with a typo, oops)

And here's a screenshot showing the issue. The content ends up truncated entirely on the right edge, and clipped-off-onto-another-page on the bottom edge.

Adds a "has-page-rule" events in print.js when the PrintPreviewCallback returns that an AtPage size was found in a document.

*When a page size is found, this enables a new "Default" scale that applies the current behavior of using the AtPage size but shrinking to the paper size if smaller.
*"Fit to page width" will set UsePageRuleSize as false to stop applying the page size and use the paper size instead.
*"Scale" will apply the given scale to the Page size, shrinking or expanding the page size accordingly instead of just the content.

For the PDF printer, which has UsePageRuleSizeAsPaperSize set to true, the scale is always set to the new default option and no UI to scale or fit the output is shown as the Paper and Page sizes will always be the same.

  • When a page size is found, this enables a new "Default" scale that applies the current behavior when a AtPage size is present.
  • "Fit to page width" will apply a scale to the paper size to fit it to the width the selected paper, keeping size ratio the same.
  • "Scale" will apply the given scale to the Page size, shrinking or expanding the page size accordingly instead of just the content.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: