1882056 - [macOS] Save to PDF print-target generates a surface with the wrong orientation (portrait) and crops output as a result, when the page content is explicitly landscape-sized

Status: NEW

(Core :: Printing: Output, defect)

Description

[Rares Doghi, Desktop QA]

Attachment: Cropped2.mp4

Found in

• Nightly 125.0a1 (2024-02-26)

Affected versions

• Nightly 125.0a1 (2024-02-26)
• Beta 124.0b3
• Release 123

Affected platforms

• macOS

Steps to reproduce

1. Reach https://bugzilla.mozilla.org/attachment.cgi?id=9370755
2. Hit Print and save the File to PDF
3. Open the Saved file in Firefox.

Expected result

• The File should be saved correctly.

Actual result

• The text from the File is Truncated.

Regression range
18:47.54 INFO: Last good revision: e4f39c21263f7325520d45120b6e2132e3c436f2
18:47.54 INFO: First bad revision: e5eaba75408ae99aad9253d54cd09efb8f5a50ec
18:47.54 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e4f39c21263f7325520d45120b6e2132e3c436f2&tochange=e5eaba75408ae99aad9253d54cd09efb8f5a50ec

Hi @Jonathan, can you please take a look at this issue ? it seems the regressor is Bug 1833244

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Rares Doghi, Desktop QA from comment #0)

Affected platforms

• macOS

Confirmed -- I can reproduce this on macOS (though not on Linux).

Also, just to clarify for other folks looking to test based on the screencast: the screencast in comment 0 shows a bunch of drawing, but that's not necessary -- per the STR, you can just go directly to printing (to the save-to-pdf target) to trigger the issue.

This also isn't specific to PDF; it appears to affect any document with a "landscape-flavored" @page {size:... } value. I'll post a testcase to demonstrate.

I think this is related to internal implicit-assumptions that we internally represent our page sizes "canonically" as portrait-oriented, i.e. with the larger dimension always being the height. In this case, we are apparently not living up to that consistently.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1 (just a 2x1 @page with a 2x1 div on it)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: printout of reduced testcase 1, showing the buggy results

Comment 4

[Daniel Holbert [:dholbert]]

I confirmed that comment 0's regression-range is accurate for my attached "reduced testcase 1" (as printed to Save-to-PDF target on macOS), too. The first-bad revision produces the attached "buggy results" PDF, whereas the last-good revision produces the 2in-by-1in rendering that we show in Print Preview (without any border clipped).

Comment 5

[Daniel Holbert [:dholbert]]

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

I think this is related to internal implicit-assumptions that we internally represent our page sizes "canonically" as portrait-oriented, i.e. with the larger dimension always being the height. In this case, we are apparently not living up to that consistently.

Adding see-also for bug 1836028, which I think is another case where this ^ sort of internal assumption is causing confusion.

(This bug and that one aren't duplicates, based on this one being OS-specific and that one being specific to certain categories of printer; but it's conceivable that fixing one bug might fix or get-us-closer-to-fixing the other.)

Comment 6

[Bianca Hidecuti, Desktop Test Engineering [:bhidecuti]]

Hello,
I am also able to reproduce this issue on Firefox 128.0b7, using macOS 13.6/14.4 with the following attachments: https://bug1721127.bmoattachments.org/attachment.cgi?id=9231862 / https://tetra4d.com/wp-content/uploads/2018/12/PartList-Helico.pdf