1662471 - Pref `print.always_print_silent` sometimes silently does nothing

Status: ASSIGNED

(Core :: Printing: Setup, defect, P2)

Description

[Jonathan Watt [:jwatt]]

The pref print.always_print_silent in some cases appears to cause printing to do nothing.

If I set print.always_print_silent = false and open the new print UI and print to a printer, then set print.always_print_silent = true and hit Cmd-P, it will send a print to the last printer.

If I then set print.always_print_silent = false and open the new print UI and Save-as-PDF, then set print.always_print_silent = true and hit Cmd-P, nothing happens. That would almost not be too surprising, except that the pref print_printer is still set to my physical printer. In that case it's unclear to me why printing is failing. (I haven't tried to debug yet since this isn't the top priority right now.)

We should test if this is broken with the new print UI disabled. Marking this P1 until we do that.

Comment 1

[Jonathan Watt [:jwatt]]

I'm not sure exactly what percentage of users have print.always_print_silent set (relatively small, I'm sure), but it would be good not to break things for them.

Comment 2

[Emil Ghitta, QA [:emilghitta]]

Hi Jonathan!

(In reply to Jonathan Watt [:jwatt] from comment #0)

If I then set print.always_print_silent = false and open the new print UI and Save-as-PDF, then set print.always_print_silent = true and hit Cmd-P, nothing happens. That would almost not be too surprising, except that the pref print_printer is still set to my physical printer. In that case it's unclear to me why printing is failing. (I haven't tried to debug yet since this isn't the top priority right now.)

When you reach this part ^ are you just selecting the Save-as-PDF destination or are you performing the actual Save-as-PDF?

I tried to reproduce this issue (on my Windows 10) and for me, when I previously saved the file as pdf, it outputs the The selected printer could not be found. error message and Uncaught (in promise) undefined is prompted inside the browser console (without the link to a certain code line number).

The print_printer pref, after doing those steps, has the value of Mozilla Save to PDF

Comment 3

[Jonathan Watt [:jwatt]]

The recent v82 regressions have shown that we have a bunch of companies and individuals (Release only, presumably) using silent printing to print labels, receipts, tickets, etc. It looks like shipping the new UI with broken silent printing could seriously disrupt some folks businesses, so we should really figure out how much of an issue this is and possibly fix it. Bumping back to P1 accordingly to make sure this is noticed.

Comment 4

[Emil Ghitta, QA [:emilghitta]]

I have managed to reproduce this issue on macOS 10.14 with the old ui. The following error message is thrown inside the browser console: TypeError: tab is undefined LinkHandlerParent.jsm:46:15

Comment 5

[Sean Voisen (:svoisen)]

ni? Emilio to investigate for 84 as cycles allow.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

This seems to work for me on Linux... Emil, what steps did you take to repro this?

Comment 7

[Emil Ghitta, QA [:emilghitta]]

Sure...Unfortunately I don't have a Linux machine configured at the moment but I can post the steps which reproduces this for me on my macOS & Windows machines:

For the Old UI: (Reproducible with macOS only for me)

Preconditions

• Have a physical printer installed.

Steps to reproduce

1. Launch Firefox with a fresh profile.
2. Open the Print setup and print a random page to your physical printer.
3. Open the Print setup again and print a random page to pdf.
4. Open the about:config page and set print.always_print_silent pref to true.
5. Open a random page and hit CTRL + P.

Actual Result

• No print job is initiated.

Expected Result

• The print job is initiated to your actual physical printer (I suppose) since the print_printer pref has the value of your actual physical printer.

New UI (Reproducible on both Windows & macOS. Maybe Ubuntu is affected as well so I'm leaving the ni? on myself to verify this once I have the Linux machine up and ready).

It seems that, for me, the value of print_printer pref is no longer pointing to the physical printer (which, I think, is expected) but some differences can be spotted after following the above steps:

There are some differences between the Save to PDF & Microsoft Print to PDF which seems to affect the silent printing:

Save to PDF

1. Print a random webpage using the "Save to PDF" destination.
2. Set the print.always_print_silent to true
3. Hit Ctrl + P

Actual Result

• The print_printer value is set to "Mozilla Save to PDF" but no print is initiated (the silent printing silently does nothing)

Expected Result

• The save to pdf print job is initiated.

Please note that if the Microsoft Print to PDF was set as a previous destination ( the print_printer pref has the value of "Microsoft Print to PDF") the print to pdf job is successfully initiated while the silent printing is active.

Comment 8

[Emil Ghitta, QA [:emilghitta]]

The behavior from comment 7 for the new UI can be reproduced on Ubuntu as well.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

The print_printer value is set to "Mozilla Save to PDF" but no print is initiated (the silent printing silently does nothing)

I still cannot repro this. The print job works and I get a PDF on the last saved location :/

Comment 10

[Emil Ghitta, QA [:emilghitta]]

Ok...so this was my bad :/ .

I've double checked now on (Windows and macOS) and noted the print.printer_Mozilla_Save_to_PDF.print_to_filename pref.

On macOS:
It seemed that it has just overridden an existing file (with the same name). This is very confusing since no warning is displayed and this action is performed in the background.

So to resume what I did.. I had a folder in which is saved via pdf file "x", switched to silent printing, and printed another page. Since the
print.printer_Mozilla_Save_to_PDF.print_to_filename pref had the same, previous, value set as "/Users/svuser/Desktop/untitled folder 3/x.pdf" it just went on to override that file with the new content (from silent printing print) without any warning.

On windows...I'm hitting the "Selected printer could not be found" again...

Comment 11

[Emil Ghitta, QA [:emilghitta]]

Attachment: Windows.gif

Comment 12

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

Attachment: silent printer ubuntu.webm

I've encountered an issue with silent printing on Ubuntu 20.04. Whilst the destination is set to the HP printer, if print.always_print_silent is set to true then it will simply print a Output.pdf file in Documents folder.

Tried having the printer connected with a usb (and it's corresponding drivers) and tried over Wifi (driverless) and the same output.pdf will be printed when print.always_print_silent is set to true.

If print.always_print_silent is set to false, then the printing job is done as expected with the physical printer.

The actual issue can be seen in the attachment. And the model of this printer is: HP Officejet 6500A Plus - E710n

Comment 13

[Sia]

I can re-produce this on my Windows machine, version 90.0 (64-bit). Error only happens when the last print method was "Save to PDF". Then switch the print.always_print_silent to true will produce a popup that says "printer could not be found".

I am trying to use this with selenium to save a page as pdf.

Comment 14

[Daniel Holbert [:dholbert]]

I ran across this when re-triaging our list of S2 bugs. jwatt, could you check if this is still reproducible for you? (If not, maybe we can close? And if so, I wonder if the severity is really S2 given that it sounds like the issue only happens once, immediately after you set the pref, and only under certain conditions?)

(In reply to Sia from comment #13)

I can re-produce this on my Windows machine, version 90.0 (64-bit). Error only happens when the last print method was "Save to PDF". Then switch the print.always_print_silent to true will produce a popup that says "printer could not be found".

Hmm, that popup sounds potentially like a different issue; it doesn't look like any of the earlier comments here mentioned a popup like this. This bug was specifically about the print silently failing.

(Or maybe something changed such that we now generate a popup instead of silently failing? As of 8 months ago when comment 13 was posted, at least.)

Comment 15

[Emilio Cobos Álvarez (:emilio)]

we've changed this substantially, is this still an issue now?

Comment 16

[Daniel Holbert [:dholbert]]

Still not clear whether this is still an issue. To the extent that it is, though, this feels probably more S3 than S2 severity at this point.

Comment 17

[Raluca Popovici, Desktop QA]

I was able to reproduce this issue (print.always_print_silent = true) on Ubuntu 22 using Fx 109.0b2, Fx 108.0, Nightly 110.0a1 and Fx 102.6.0 esr.

Comment 18

[Daniel Holbert [:dholbert]]

Hmm, yeah; I'm seeing this as well, on Ubuntu (with my system currently configured to have only one printer, Firefox's built-in PDF printer).

With the pref set: if I do Ctrl+P or window.print(), I don't see any PDF file being generated.

In a debug build, I get this output every time I do Ctrl+P:

[Parent 211110, Main Thread] WARNING: Caller should supply a printer name.: file /scratch/work/builds/mozilla-central/mozilla/widget/nsPrintSettingsService.cpp:916
[Child 211328, Main Thread] WARNING: NS_ENSURE_TRUE(rootView) failed: file /scratch/work/builds/mozilla-central/mozilla/layout/base/nsPresContext.cpp:1146
[GFX3-]: Surface size too large (exceeds extent limit)!
[GFX2-]: Allowing surface with invalid size (Cairo) Size(48960,63360)
[GFX3-]: Surface size too large (exceeds extent limit)!
[GFX2-]: Allowing surface with invalid size (Cairo) Size(48960,63360)

I suspect the first line ("Caller should supply a printer name.") might be pointing at the issue here. I don't see that when I unset the pref and just click through the print dialog, accepting defaults.

Comment 19

[Daniel Holbert [:dholbert]]

side note: if I attempt to print parent-process content (E.g. about:config or about:preferences) with the silent printing pref activated, in a debug build, then I get a fatal assert; see bug 1663623.