1980356 - PDFs Print as Blank Pages, with `print.prefer_system_dialog`, if you use the print button inside the PDF-viewer UI

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[iYx3Zp8Q08hrNVZCHTYt]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

1. Open Firefox ESR version 128.13.0.
2. Ensure print.use_system_print_dialog is set to true in about:config.
3. Open any PDF file within Firefox (inline PDF rendering via built-in viewer PDF.js).
4. Click on the Print button in the PDF viewer toolbar.
5. Choose printer and proceed with printing from the system print dialog.

Actual results:

PDFs result in completely blank printed pages.

Expected results:

All PDF documents should print normally, with their visible content rendered in the printed output.

Comment 1

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

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 2

[Daniel Holbert [:dholbert]]

Hmm, this sounds similar to bug 1980082 (with slightly different outcome).

Did this work properly in Firefox ESR 128.12.0 (previous dot-release)?

(This might be a regression from bug 1959052 (whose patch was part of 128.13.0). Tentatively marking as such...)

Comment 3

[iYx3Zp8Q08hrNVZCHTYt]

I checked with the previous version (ESR 128.12.0), and found that it prints without any issues. As a matter of fact, My Organization used the same version till last week. This printing issue came just after updating it to ESR 128.13.0 last Wednesday. I also tried testing this issue with different versions and found that Firefox 141.0 (stable), also have this same issue.

I performed regression testing as requested. Here's a summary of the results:

• Firefox ESR 128.12.0 → PDF printing works as expected using the system print dialog.
• Firefox ESR 128.13.0 → PDF printing produces blank pages.
• Firefox 141.0 (stable) → Also affected; blank pages when printing PDFs with system print dialog.

Tested on:

• Linux (x86_64)
• Windows 10

The issue occurs when:

• print.use_system_print_dialog is set to true
• A PDF is opened using Firefox's built-in PDF viewer (PDF.js)
• Printing is done via the system print dialog

Everything prints blank, regardless of printer selection or system.

Comment 4

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

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

For more information, please visit BugBot documentation.

Comment 5

[Daniel Holbert [:dholbert]]

Thanks for that testing! My apologies - it turns out I can reproduce, I had just gotten my printed output mixed up.
I can reproduce in 128.13.0 ESR as well as current Nightly 143.0a1.

Here's a profile in Nightly 143.0a1: https://share.firefox.dev/3IX3UJ8
Interestingly, the print button stays pressed for an unusually long time after I click through the system print dialog.

Notably:
This only reproduces with print.use_system_print_dialog (i.e. not when I click through from the regular print dialog to the system print dialog), and it also only reproduces if you use the print button in the PDF viewer (no issues if you use Ctrl+P).

Comment 7

[Daniel Holbert [:dholbert]]

In my profile from comment 5 (which had printing:5 logging enabled in about:logging) there are a series of log statements about print failure at around t=16s:

nsPagePrintTimer - nsPagePrintTimer::Fail aborting print operation
LogMessages — (printing) ****  Failed Print Preview - rv 0x0
PrintJob - nsPrintJob::CleanupOnFailure
PrintJob - nsPrintJob::FirePrintingErrorEvent
DOMEvent — PrintingError - document
SendAsyncMessage - [Printing] Printing:Error

Here's the profile zoomed to that range: https://share.firefox.dev/479KBWY

It looks like something must have gotten stuck, and the nsPagePrintTimer times out and aborts the operation so that we're not stuck forever.

Comment 8

[Daniel Holbert [:dholbert]]

Few more quick notes:
(1) I'm using https://bug1928148.bmoattachments.org/attachment.cgi?id=9434291 as my testcase here, as a simple PDF.

(2) Short-term workaround for this issue (for affected folks, who have print.prefer_system_dialog): you can still print by just using a different button/command -- just avoid the one at the top-right of the pdf-viewer UI. e.g. you can print with Ctrl+P/Cmd+P, or Hamburger-Menu | Print -- both of those workflows work for me at least. (I think this bug is specific to the "initiated-from-the-content-itself" print flow [and the button here is technically part of the web content]).

(3) I confirmed this bug affects the Ubuntu/GTK "Print to File" print-target in the system print dialog -- that ends up generating an entirely blank PDF when I follow the steps-to-reproduce here with that print target. So that'll hopefully help to save paper when further testing/diagnosing this.

Comment 9

[Jonathan Kew [:jfkthame]]

It feels like the ghost of bug 1898184 is still around to trouble us. If I'm reading your profile right, it looks like we're stuck in the SpinEventLoopUntil call here, and its "until" condition is never becoming true.

We tried to fix that in bug 1898184, but that caused new issues, so in bug 1959052 we reverted that and tried a different approach; but it seems that there's still a case that isn't being handled properly.

Comment 10

[Daniel Holbert [:dholbert]]

Here's a pernosco trace of this reproducing in a debug build (with print logging enabled):
https://pernos.co/debug/QYvJRcSJQk7yMAJZPg5eNw/index.html

In that run (and maybe always when testing this in a debug build), we fail a fatal assertion:

Assertion failure: !mRecorder->IsOpen(), at widget/nsDeviceContextSpecProxy.cpp:129

I'll dig a bit more at the trace tomorrow to see what I can find out about how things are going amiss...

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Comment 12

[Daniel Holbert [:dholbert]]

Attached reduced testcase reproduces the bug. STR are to print using the button in the testcase, just like with actual PDFs above. This produces a blank PDF, and the button stays in its "pressed" state for ~8 seconds while Firefox is generating that PDF.

The relevant factors seem to be:
(1) printing using window.print()
(2) having print.prefer_system_dialog set to true
(3) using mozPrintCallback to dynamically render some content to a canvas at print time (as PDF.js does)
(4) waiting for some delay before calling obj.done() in mozPrintCallback (in this testcase, I use setTimeout; but in PDF.js, this would be e.g. waiting for fonts to load and stuff like that).

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: reference case 1 (with obj.done() being called synchronously)

Here's a modified version of the testcase where I removed the setTimeout (factor #4 from my previous comment); with that edit, things work as-expected.

Comment 14

[Daniel Holbert [:dholbert]]

I captured some pernosco traces with the reduced testcase & reference case, which might be easier to reason about than my comment 10 pernosco trace with PDF.js.

Printing failure with reduced testcase 1, unmodified sources:
https://pernos.co/debug/_C7TY2ewe086X08Qbqs0dA/index.html

Printing successfully with reference case 1, unmodified sources:
https://pernos.co/debug/YYsNiy_fMQ4EZAzGbBk0LQ/index.html

Printing successfully with reduced testcase 1, sources modified to back out the regressing patch (which is why we're successful):
https://pernos.co/debug/0W-tDLh6_QhmpFb7bDawcw/index.html

Comment 15

[Daniel Holbert [:dholbert]]

I've got a patch locally; just polishing up a test for it.

It won't make it in time for next week's release, but there's a chance it'd be a ridealong for a mid-cycle release. Otherwise I anticipate it'll be shippable with the following release, which goes out in just over 4 weeks.

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: Bug 1980356: Don't block in window.print() if there's a registered mozPrintCallback (e.g. for PDF.js) and if any sort of print dialog might be up. r?emilio

Before this patch, we would unconditionally block in window.print() if the user
had the system print dialog enabled. That was problematic because it prevents
mozPrintCallback from doing asynchronous work, as described in the nearby
code-comment, and this resulted in PDFs printing blank for such users if they
used the "print" button (which triggered window.print()).

This patch makes the print.prefer_system_dialog codepath share the same logic
flow as the regular-print-preview codepath -- now we will not block if
there's a registered print callback (which allows the callback's microtasks to
proceed while the print dialog is still up).

Comment 17

[iYx3Zp8Q08hrNVZCHTYt]

Since this is marked wontfix for ESR 128.x, could you clarify if the fix is expected to land in the ESR 140.x line?

Also, based on Comment 15, it sounds like the patch might ship with Firefox 143 or possibly a mid-cycle update. Just wanted to check if the fix will also make it into the corresponding ESR release, or if it's limited to the regular Firefox channel for now.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7e2571a2741b
https://hg.mozilla.org/integration/autoland/rev/6c0d8776367a
Don't block in window.print() if there's a registered mozPrintCallback (e.g. for PDF.js) and if any sort of print dialog might be up. r=emilio

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to iYx3Zp8Q08hrNVZCHTYt from comment #17)

Since this is marked wontfix for ESR 128.x, could you clarify if the fix is expected to land in the ESR 140.x line?

Thanks - I think that was an oversight. I've restored "affected" for esr128.

This bug is a regression caused by a patch (in bug 1959052) that we uplifted to ESR128 and 140, and I think the fix should be uplifted as well to address the regression on those branches. I intend to request uplift-approval (to 128esr, 140esr, and 143beta) in a day or two, once the fix has been verified on Nightly 144. In all of those cases, I think it's likely it'll reach release in ~4 weeks (the week of Sept 15, our next release week).

Comment 20

[Jonathan Kew [:jfkthame]]

The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does window.print(); window.close().

The original report in bug 1959052 indicates that window.print(); window.close() is a pattern seen (at least sometimes) in the wild; and it makes sense in the context of a window that is being presented just for the purpose of being printed. But if such a window has pdf.js content, or for some other reason uses mozPrintCallback, this isn't going to work.

Is there a way we could do some kind of "selective script blocking" that would block just the script that called window.print() but allow others such as mozPrintCallback to execute?

Comment 21

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/6c0d8776367a

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew [:jfkthame] from comment #20)

The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does window.print(); window.close().

The original report in bug 1959052 indicates that window.print(); window.close() is a pattern seen (at least sometimes) in the wild; and it makes sense in the context of a window that is being presented just for the purpose of being printed. But if such a window has pdf.js content, or for some other reason uses mozPrintCallback, this isn't going to work.

Right, that specific use-case (opening a PDF or something with mozPrintCallback in a popup, and then doing window.print();window.close()) will regress to the pre-bug 1959052-bugfix state, for users with print.prefer_system_dialog. I think that's an acceptable tradeoff here for the time being; such content is likely rare (much rarer than folks wanting to just view a PDF and click print, at least.

I'll come up with a testcase that fails in that way and file a followup to look into addressing that. [leaving ni=me open]

Is there a way we could do some kind of "selective script blocking" that would block just the script that called window.print() but allow others such as mozPrintCallback to execute?

I'm not sure, but something like that would definitely be ideal. It seems like we manage to do that with our own tab-modal print dialog (at least, bug 1959052 didn't affect our tab-modal print dialog), so maybe we need to investigate how that manages to work a bit more, and draw inspiration from that.

Comment 23

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew [:jfkthame] from comment #20)

The concern I have with this is that IIUC it'll regress the situation that bug 1959052 was originally concerned with, in the case where there's a callback and the print button (or equivalent) does window.print(); window.close() [...] if such a window has pdf.js content, or for some other reason uses mozPrintCallback,

So, two pieces of good news:
(1) We never got this case actually-working (with PDF/mozPrintCallback content at least); bug 1959052 made this hypothetical-scenario go from "popup window mysteriously closes" to "popup window mysteriously prints blank pages instead of the actual PDF". So the patch that I landed here didn't really regress that case; it was never really working in the first place.

(2) That case (PDF opened in popup-window, with window.print();window.close()) is actually broken in Chrome as well, and in Firefox with the regular print dialog. I've got some testcases in bug 1985400 to demonstrate.

So: this is all good news because it means that the potential regression "cost" of taking this patch (that jfkthame describes in comment 20) is not actually a regression [that situation was & continues to be broken] and it's also not likely to be something that web content is likely to do since it's similarly broken in Chrome. Possibly nobody bothers to rely on doing that sort of thing, because you can't robustly run your own random scripts in window.open()-spawned PDF document, because you have no idea what sort of environment will be displaying it (whether PDF.js or PDFium or an embedded plugin or something else)

Comment 24

[Daniel Holbert [:dholbert]]

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

(In reply to iYx3Zp8Q08hrNVZCHTYt from comment #17)

Since this is marked wontfix for ESR 128.x, could you clarify if the fix is expected to land in the ESR 140.x line?

Thanks - I think that was an oversight. I've restored "affected" for esr128. [...] I intend to request uplift-approval (to 128esr, 140esr, and 143beta)

Correcting myself -- ESR128 is actually end-of-life after this release cycle, so there's no update that this patch could ship in, for that version.

https://whattrainisitnow.com/release/?version=esr shows the next release day being Sept 16, with ESR128 officially becoming end-of-life on that day (at which point I think its users will be offered a update to ESR 140.3)

So: wontfix is actually correct for that release train, but I'll request uplift for ESR140.

Comment 25

[Daniel Holbert [:dholbert]]

Attachment: Bug 1980356: Don't block in window.print() if there's a registered mozPrintCallback (e.g. for PDF.js) and if any sort of print dialog might be up. r?emilio

Before this patch, we would unconditionally block in window.print() if the user
had the system print dialog enabled. That was problematic because it prevents
mozPrintCallback from doing asynchronous work, as described in the nearby
code-comment, and this resulted in PDFs printing blank for such users if they
used the "print" button (which triggered window.print()).

This patch makes the print.prefer_system_dialog codepath share the same logic
flow as the regular-print-preview codepath -- now we will not block if
there's a registered print callback (which allows the callback's microtasks to
proceed while the print dialog is still up).

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

Comment 26

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Print failures for users who use the print button in our PDF viewer, and who have the print.prefer_system_dialog about:config pref set to true.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Load https://bug1928148.bmoattachments.org/attachment.cgi?id=9434291 ; click the Print button inside the PDF viewer UI (near the top right of the tab's content area); complete the print (to a real or virtual printer) and inspect the output. Expected results are for "Simple PDF example" to appear. Buggy result is a fully-blank printout.
• Risk associated with taking this patch: Low
• Explanation of risk level: This is essentially a partial backout of the regressor (bug 1959052), restoring the old behavior under certain conditions. And per comment 23, there's very little downside to doing that.
• String changes made/needed: None
• Is Android affected?: no

Comment 27

[Daniel Holbert [:dholbert]]

Attachment: Bug 1980356: Don't block in window.print() if there's a registered mozPrintCallback (e.g. for PDF.js) and if any sort of print dialog might be up. r?emilio

Before this patch, we would unconditionally block in window.print() if the user
had the system print dialog enabled. That was problematic because it prevents
mozPrintCallback from doing asynchronous work, as described in the nearby
code-comment, and this resulted in PDFs printing blank for such users if they
used the "print" button (which triggered window.print()).

This patch makes the print.prefer_system_dialog codepath share the same logic
flow as the regular-print-preview codepath -- now we will not block if
there's a registered print callback (which allows the callback's microtasks to
proceed while the print dialog is still up).

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

Comment 28

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Print failures for users who use the print button in our PDF viewer, and who have the print.prefer_system_dialog about:config pref set to true.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Load https://bug1928148.bmoattachments.org/attachment.cgi?id=9434291 ; click the Print button inside the PDF viewer UI (near the top right of the tab's content area); complete the print (to a real or virtual printer) and inspect the output. Expected results are for "Simple PDF example" to appear. Buggy result is a fully-blank printout.
• Risk associated with taking this patch: Low
• Explanation of risk level: This is essentially a partial backout of the regressor (bug 1959052), restoring the old behavior under certain conditions. And per comment 23, there's very little downside to doing that.
• String changes made/needed: None
• Is Android affected?: no

Comment 29

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/a19ee721bd9f
https://hg.mozilla.org/releases/mozilla-beta/rev/b8313117d0b9

Comment 30

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/4a22ddc38010

Comment 31

[Peter Magyari (Desktop QA)]

Verified fixed using Nightly 144.0a1 (20250827210442), Beta 143.0b5 (20250827090822) and 140.3.0esr (20250827030455) on Windows 10, MacOS 15 and Ubuntu 24.04.