2047850 - Printing via system print dialog no longer works on Mac

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[JJP]

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

Steps to reproduce:

When printing to PDF via the system print dialog, either by clicking "Print using the system dialog", or alternatively by having print.prefer_system_dialog set to "true", the file is not printed/saved.

This bug is new with 152 and has been tested on a new profile and on two different machines.

Actual results:

Nothing happens when an attempt is made to print/save.

Expected results:

A PDF should result.

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 3

[Ryan VanderMeulen [:RyanVM]]

For people who can reproduce this, it would be super helpful if a regression range could be identified using the mozregression tool. You can run it without any risk to your normal Firefox profile.
https://mozilla.github.io/mozregression/

Comment 4

[Stephen A Pohl]

Attachment: Bug 2047850: Read system print dialog results from the printInfo passed to the sheet on macOS. r=#mac-reviewers

Bug 2035195 migrated the macOS system print dialog from -[NSPrintPanel runModal] to the delegate-based -beginSheetWithPrintInfo:modalForWindow:delegate:didEndSelector:contextInfo: sheet API. With runModal, NSPrintPanel updates the printInfo of the current NSPrintOperation, so the completion code read the user's choices back from [[NSPrintOperation currentOperation] printInfo]. The sheet API instead writes the user's choices, including the print destination, back into the printInfo object that is passed to it, not into the copy held by the current NSPrintOperation.

The completion block kept reading from the current operation's copy, which is never modified by the sheet, so the destination selected in the dialog (for example "Save as PDF") was lost and the job most likely fell back to the default printer. Read the updated settings from the printInfo we passed to beginSheetWithPrintInfo: instead.

Comment 5

[Stephen A Pohl]

Printing to PDF via the built-in dialog still works, so setting severity to S3 for now.

Kicked off try build with a fix: https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=58329

Waiting for local build to complete and confirm the fix before requesting review.

Comment 6

[Stephen A Pohl]

I have verified the patch locally. If anyone else could verify the fix, I would appreciate it. Here is a signed build with the fix. To run this build you will need to follow these steps:

1. Download the build: https://firefoxci.taskcluster-artifacts.net/f91pjEw3Srq5GX9KdM5OsQ/0/public/build/target.tar.gz
2. Extract it by double-clicking it in Finder. This produces "Firefox Nightly.app".
3. Clear the quarantine flag from Terminal so macOS will let it run (adjust the path if you extracted it elsewhere):

xattr -dr com.apple.quarantine ~/Downloads/Firefox\ Nightly.app

4. Launch it by double-clicking it.

Thank you!

Comment 7

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! I have reproduced the issue on macOS 26 aarch, 14 aarch and 10.15 Intel with Firefox 154.0a1 (2026-06-16). Printing Wikipedia to PDF using the system dialog will not save a PDF file.
The file is correctly saved when printing via PDF using the system dialog with print.prefer_system_dialog: true or false with the build from comment 6 on macOS 26 aarch, 14 aarch, and 10.15 Intel. If more information is needed, please let me know. Thanks!

Comment 9

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Printing to PDF via the system print dialog on macOS will forward the print job to the default printer, which may be a physical printer. No PDF file is generated.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Test 1:
  Print a page (Cmd+P).
  Select the system print dialog.
  Press the PDF button -> Should generate PDF.

Test 2:
Print a page (Cmd+P).
Select the system print dialog.
Press the dropdown arrow next to the PDF button.
Select "Save as PDF..." -> Should generate PDF.

• Risk associated with taking this patch: low
• Explanation of risk level: This is a well-understood one line change that restores previous behavior prior to the regressing bug 2035195.
• String changes made/needed?: None
• Is Android affected?: no

Comment 10

[Stephen A Pohl]

Attachment: Bug 2047850: Read system print dialog results from the printInfo passed to the sheet on macOS.

Bug 2035195 migrated the macOS system print dialog from -[NSPrintPanel runModal] to the delegate-based -beginSheetWithPrintInfo:modalForWindow:delegate:didEndSelector:contextInfo: sheet API. With runModal, NSPrintPanel updates the printInfo of the current NSPrintOperation, so the completion code read the user's choices back from [[NSPrintOperation currentOperation] printInfo]. The sheet API instead writes the user's choices, including the print destination, back into the printInfo object that is passed to it, not into the copy held by the current NSPrintOperation.

The completion block kept reading from the current operation's copy, which is never modified by the sheet, so the destination selected in the dialog (for example "Save as PDF") was lost and the job most likely fell back to the default printer. Read the updated settings from the printInfo we passed to beginSheetWithPrintInfo: instead.

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

Comment 11

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Printing to PDF via the system print dialog on macOS will forward the print job to the default printer, which may be a physical printer. No PDF file is generated.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Test 1:
  Print a page (Cmd+P).
  Select the system print dialog.
  Press the PDF button -> Should generate PDF.

Test 2:
Print a page (Cmd+P).
Select the system print dialog.
Press the dropdown arrow next to the PDF button.
Select "Save as PDF..." -> Should generate PDF.

• Risk associated with taking this patch: low
• Explanation of risk level: This is a well-understood one line change that restores previous behavior prior to the regressing bug 2035195.
• String changes made/needed?: None
• Is Android affected?: no

Comment 12

[Stephen A Pohl]

Attachment: Bug 2047850: Read system print dialog results from the printInfo passed to the sheet on macOS.

Bug 2035195 migrated the macOS system print dialog from -[NSPrintPanel runModal] to the delegate-based -beginSheetWithPrintInfo:modalForWindow:delegate:didEndSelector:contextInfo: sheet API. With runModal, NSPrintPanel updates the printInfo of the current NSPrintOperation, so the completion code read the user's choices back from [[NSPrintOperation currentOperation] printInfo]. The sheet API instead writes the user's choices, including the print destination, back into the printInfo object that is passed to it, not into the copy held by the current NSPrintOperation.

The completion block kept reading from the current operation's copy, which is never modified by the sheet, so the destination selected in the dialog (for example "Save as PDF") was lost and the job most likely fell back to the default printer. Read the updated settings from the printInfo we passed to beginSheetWithPrintInfo: instead.

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

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b226a07008a4
https://hg.mozilla.org/integration/autoland/rev/3ca05acd08e0
Read system print dialog results from the printInfo passed to the sheet on macOS. r=mac-reviewers,mstange

Comment 14

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/c9565d2c7f82
https://hg.mozilla.org/releases/mozilla-beta/rev/86240ace22b0

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/286dcd225ad3
https://hg.mozilla.org/releases/mozilla-release/rev/f6f506872a4b

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Added to the 152.0.1 relnotes.

Comment 17

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Verified fixed with Firefox 152.0.1 and 153.0b2 from comment 14 on macOS 10.15 and 12 Intel and macOS 14 aarch and macOS 26 aarch using steps from comment 11. Printing using PDF and the system print dialog correctly creates the file while having a printer available without also printing on the printer. Note that we encountered bug 2048541 when printing to PDF without the system dialog.

Comment 18

[rperta]

https://hg.mozilla.org/mozilla-central/rev/3ca05acd08e0

Comment 20

[Max Emig [:maxe]]

This was in the real Thunderbird 152 release, a fix might deserves a mention somewhere.