1970805 - HTML Spec page fails to print to PDF

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P3)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: print preview error.png

Found in

• Firefox 140.0b5

Affected versions

• Firefox 140.0b5
• Firefox 141.0a1

Tested platforms

• Affected platforms: All

Steps to reproduce

1. Access this page
2. Open the print preview and wait for the preview to fully load
3. Print the page to PDF

Expected result

• The page is printed

Actual result

• A brief message appears stating "An error occurred while printing" is shown and the output file is corrupt and cannot be opened

Regression range

• Looked for regression and it seems that this was introduced between 2024-12-04 and 2024-12-05. Bug 1929461 was shown in the pushlog.

Additional notes

• The issue can be seen in the attachments
• Print preview will take some time to be shown as there are ~1000 pages to load
• Browser console will throw some errors as well.

Comment 1

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Attachment: br console and corrupt file.png

Comment 2

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

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

:jfkthame, since you are the author of the regressor, bug 1929461, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Jonathan Kew [:jfkthame]]

Interesting.... I was able to confirm that on macOS, with a build from 2024-12-04 I get a successfully-generated PDF, while with 2024-12-05 it is truncated/broken. However, on Windows it is broken both before and after that date; neither build creates a usable PDF.

The patch in bug 1929461 only changes behavior if we get a DrawTarget that is marked as Invalid; so I guess that must be happening here, but prior to bug 1929461 we were ignoring the error, and it was not actually fatal on macOS (whereas in some other cases it could result in a crash, which is what we wanted to avoid).

Comment 4

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

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

Comment 5

[Pascal Chevrel:pascalc]

Do we want to fix this regression for 141? Thanks

Comment 6

[Jonathan Kew [:jfkthame]]

I think the odds are against it at the moment. We need a better understanding of the error condition that's arising than we currently have, and debugging this is likely to be a slow process. :(

Comment 7

[Jonathan Kew [:jfkthame]]

Weird -- today, I'm not able to reproduce the failure on Windows at all; it's successfully generating a complete 998-page PDF. I first tried with my local Nightly build, intending to try and narrow down the issue, but it succeeded. So then I used mozregression to try builds from 2024-12-04/05 (compare comment 3), and these also succeeded, despite having failed last week. What's changed? I don't know.

The issue does reproduce for me on macOS, so I'm trying to get some insight into what's happening...

Comment 8

[Jonathan Kew [:jfkthame]]

It seems that we're getting an error (returned as "out of memory" by cairo, though I think this is misleading -- the real issue is an unexpected CGContext type) inside cairo from _cairo_quartz_surface_map_to_image, which then propagates up to the cairo context and results in the DrawTarget becoming invalid. This causes Recorded{whatever}::PlayEvent to return false, and the playback of the recording bails out.

(In the case of the big HTML spec, checking the output from a "working" version (prior to bug 1929461), I notice that some content is missing from section 4.8.4.1, including the "magnifying-glass" superimposed on the mobile-screen image examples. I'm guessing it may be the pattern fill within the SVG image that's triggering an error condition in the cairo-quartz backend, though I have not yet specifically verified this.)

To handle this better, we should not entirely abort playback if the DrawTarget's context is in an error state; instead, we can just skip attempting to do any actual drawing operations to it -- to avoid issues like the crash in bug 1929461 -- but allow playback to continue. This may result in some content missing from the output, but is better than failing to generate a valid PDF at all.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1970805 - Remove validity check from Translator::GetCurrentDrawTarget to avoid aborting print-job playback, and add drawtarget-validity checks to more methods in DrawTargetCairo. r=#gfx-reviewers

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6993cdd7e2af
https://hg.mozilla.org/integration/autoland/rev/ac7e098bc5b1
Remove validity check from Translator::GetCurrentDrawTarget to avoid aborting print-job playback, and add drawtarget-validity checks to more methods in DrawTargetCairo. r=gfx-reviewers,lsalzman,jrmuizel

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/79396de8796d
https://hg.mozilla.org/integration/autoland/rev/5bfd1afd5ca1
Revert "Bug 1970805 - Remove validity check from Translator::GetCurrentDrawTarget to avoid aborting print-job playback, and add drawtarget-validity checks to more methods in DrawTargetCairo. r=gfx-reviewers,lsalzman,jrmuizel" for causing wpt assertion failures in PrintTranslator.h.

Comment 12

[Serban Stanca [:SerbanS]]

Reverted this because it was causing wpt assertion failures in PrintTranslator.h.

• Revert link
• Push with failures
• Failure Log
• Failure line: Assertion failure: result, at /builds/worker/checkouts/gecko/layout/printing/PrintTranslator.h:54

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e0b19141c9ef
https://hg.mozilla.org/integration/autoland/rev/57ca0dcab3ca
Remove validity check from Translator::GetCurrentDrawTarget to avoid aborting print-job playback, and add drawtarget-validity checks to more methods in DrawTargetCairo. r=gfx-reviewers,lsalzman,jrmuizel

Comment 14

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/57ca0dcab3ca

Comment 15

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I've verified that the issue is fixed on Firefox 142.0a1 (2025-07-20) on macOS 15.5.

It seems though that Ubuntu 24.04 and Windows 11 will print the file, but I was able to open them only on Chrome. I tried Firefox and Edge on Windows and they wouldn't open the printed PDF, and on Ubuntu I tried the system document reader and Firefox and still no luck.

I'll mark this as verified on 142 as the files are printed, but should I file a new issue for the windows/ubuntu thing?

Comment 16

[Jonathan Kew [:jfkthame]]

It may be that the file is so big that it's exceeding some limitation in pdf.js, but seems worth at least looking into it. So a new issue (in the PDF Viewer component) sounds like the right way forward.

Comment 17

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Logged Bug 1978317 as a follow up. Thanks!

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Should we uplift this to ESR140 also? Please nominate if yes.

Comment 20

[Jonathan Kew [:jfkthame]]

Yes, I think we should uplift to esr140. We should probably consider taking the followup bug 1978317 as well, although the situation that's addressing (wallpapering, really) is more extreme edge-caseish.

Comment 21

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1970805 - Remove validity check from Translator::GetCurrentDrawTarget to avoid aborting print-job playback, and add drawtarget-validity checks to more methods in DrawTargetCairo. r=#gfx-reviewers

Original Revision: https://phabricator.services.mozilla.com/D255099

Comment 22

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: A cairo error condition during printing (e.g. some kind of content it can't handle) results in print failure / broken PDF output
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Load the big HTML spec https://html.spec.whatwg.org/ and print to the Save to PDF destination
• Risk associated with taking this patch: low
• Explanation of risk level: Patch just moves error-handling so that an error state on one page doesn't abort the entire job
• String changes made/needed: none
• Is Android affected?: yes

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/8fe3233e4df4

Comment 24

[Ciprian Georgiu, Desktop QA]

I'm not able to reproduce this bug using an affected Nightly build (2025-06-06) on Win 11 and macOS 15.

I think we need to wait until my colleague, Catalin, returns from PTO since he was able to reproduce it on his machine.

Comment 25

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that the page is printed to PDF without issues on Firefox ESR 140.3.1. Tests were performed on macOS 26.0, Windows 11 and Ubuntu 24.04.

As a note, it took a very very long time for the file to be printed to PDF on Windows 11 (by comparison with Mac and Ubuntu), but eventually it finishes the job and the file can be opened without issues.