1805994 - Firefox creates "damaged"/truncated pdfs of web pages

Status: UNCONFIRMED

(Core :: Printing: Output, defect)

Description

[jherbertbpc]

Attachment: Screen Shot 2022-12-15 at 12.34.17 PM.png

Steps to reproduce:

Tried to create a pdf of web page in Mac OS Big Sur/Monterey
Web Page > Command P > Print Using System Dialog > Save as PDF

Actual results:

Result
" The file xxx could not be opened. It may be damaged or us a file format that
Preview doesn't recognize."

Expected results:

This problem does not occur using Safari.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alin Ilea, Desktop Test Engineering]

Hi,

I have tested your issue on latest FF release 108, Beta 109.0b4 and the latest Nightly build 110.0a1 (2022-12-20) using macOS 12 but I cannot reproduce the issue. On my end the pdf is correctly saved and it can be opened/previewed without issues.
If the issue is still reproducible on your end, can you please retest this using latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile (https://goo.gl/AWo6h8) to eliminate the potential causes.
Also, please let us know what firefox version are you using.

Thanks for the report.

Comment 3

[jherbertbpc]

Still somewhat mixed results.
Test 1
Big Sur > New User > did not show the error

Test 2
Monterey > Established user > one instance of error and one non-error

Test 3 sort of an oddball test:
Big Sur
Made a pdf of a web page in Safari fine
Opened that pdf in Firefox browser then tried to save that
as a pdf ... which resulted in a "damaged" file
... I should add perhaps that Firefox pdfs are introducing a component in the file that Mac OS Preview app
cannot render

That's all I got for the moment

Comment 4

[:Gijs (he/him)]

Could you attach an example of a PDF that is broken in this way that you're comfortable sharing, so we could investigate why Preview.app is upset / what features of the (macOS-provided...) PDF printer have upset it? :-)

Comment 5

[:Gijs (he/him)]

Given this is PDF printing-related, moving to print output.

Comment 6

[jherbertbpc]

Attachment: news - Google Search.pdf

For what it's worth here is a sample pdf created in the print dialog method of a google search page.
While further experimenting yielded mixed results, this is one that is a "damaged" pdf

Comment 7

[jherbertbpc]

Attachment: Screen Shot 2022-12-23 at 2.19.44 PM.png

To test further confirm issue with the new test pdf, I downloaded and on my system the file is
still a damaged pdf

Comment 8

[Calixte Denizet (:calixte)]

The attached pdf doesn't have neither a xref nor a trailer dict and I can't open it in whatever viewer I've here.
The last stream is truncated so likely we've a partial pdf file here.
I can't reproduce the issue in Nightly with MacOS Ventura (13.1).

Comment 9

[Daniel Holbert [:dholbert]]

I was also unable to repro on MacOS Ventura (13.1)

I've got a few questions, to clarify & rule out possible variables - thanks for the bug report & thanks in advance for any help you can provide on these:

(1) Was your "Test 3" (in comment 3) with a new user account, or was that one with an established user account? (You noted the new vs. established info for Test 1 and 2 but not for Test 3. Maybe that was with the same new user account as in test 1?)

(2) Is there any pattern to what sorts of content seems to trigger the issue, in an environment where it reproduces for you?

(3 If the "undamaged" source PDF from your test 3 reliably produces damaged output when printed from Firefox (not sure), perhaps you could share that and it might provide a clue?

(4) You mentioned "Web Page > Command P > Print Using System Dialog > Save as PDF" -- do you also see this issue if you just use Firefox's own print dialog, with Firefox's included "Save to PDF" print target?

(5) You mentioned two different OS versions in comment 3 -- does that mean you've reproduced this on multiple different macOS machines? Or is that the same machine in two different boot environments/configurations?

(6) Do you know if there's any reason Firefox might be running into filesystem issues when creating the PDF? (e.g. are you saving it onto a disk with low disk space, or a network drive, or something else noteworthy like that?)

Comment 10

[jherbertbpc]

1. I am pretty sure that was back to my regular user account, not a fresh user

2. I have not discovered the pattern. At first I was thinking perhaps their might be drm protection of some sort when I tried
   to pdf a page from wash. post (to which I subscribe) But I also do this process if I want to save some sensitive information/data from
   online accounts for which I want a readable pdf rather than a web archive or screenshot.
   With similar results, but I have not narrowed down to an exact pattern or cause.

3. A I was replicating this I just noticed another oddball symptom. I created a pdf of this bug page in both Safari and Firefox.
   Firefox first > damaged file alert ... then a pdf of this same page in Safari which opened fine but here's the kicker... I then
   tried to open the Firefox pdf I had just created before and it opened .... weird.
   Bottom line this is a weirdly inconsistent phenomenon

4. That's an interesting question at the moment my few tests on this the Firefox print dialog: has not resulting in the problem
   Needs further test later on another machine... but you may have hit on to something

5. I have reproduced this on two different machines both one machine MBPro 2015 of which has Big Sur and Monterey volumes;
   the other machine MBPro 2017 running Big Sur

6. Nothing note worthy, plenty of room, no network drive relevant ...

that's the best I got for the moment

Comment 11

[Daniel Holbert [:dholbert]]

Thank you for that info. Your point 3. is very mysterious, where the file triggered the issue at first and then didn't trigger it after some time had passed. That does suggest some sort of buffered-writing or filesystem-caching sort of strangeness.

I suspect there's not much we can do to investigate right now, not being able to reproduce locally... We may be able to find out more & figure out relevant commonalities if we get more reports (or discover a way to reproduce). In the meantime: if you discover anything else that might help get us closer to solving the mystery here, please do add additional notes -- thanks!