Affected versions

• 82.0a1 (BuildId:20200907094115)
• 81.0b7 (BuildId:20200906164749)

Affected platforms

• Windows 10 64bit
• Ubuntu 18.04 64bit
• macOS 10.14

Preconditions

• Perform a print via the “Save to PDF” destination in order to have the “Save to PDF” as the default set destination next time you use the print UI.

Steps to reproduce

1. Access the following webpage.
2. Hit CTRL + P.
3. Change the destination from “Save to PDF” to your actual printer.
4. Set a custom range (ex: from 2 to 3)
5. Change the destination back to “Save to PDF”
6. Print the file.

Expected result

• The file is successfully printed.

Actual result

• After clicking the “Save” button from the “Save As” prompt, the old system dialog gets open. I’ve noted that before the system dialog gets open, an empty pdf file is generated and If you try to print with the newly open system dialog it will give you an error with the following error message being outputted inside the browser console: UnknownError: Print.

Regression Window

• This seems to be a regression.
• Pushlogh: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=44801b6e7c7a2d333c287b926a7118356c396a2d&tochange=2e2abe718eb21d36932b373f587d11819d0a3674

Additional Information

• [Suggested Severity] S2

Does this also affect the old print UI or only the new one?

Nevermind it sounds like the new UI.

It's possible bug 1662938 fixes this. (I couldn't reproduce even prior to that landing.)

Emil, once the fix for that bug makes it into a Nightly build, can you retest?

I can still reproduce this issue using the build which contains the fix from bug 1662938.

I saw a pattern (as described in comment 0) that you need to perform a Save To PDF print first as a precondition (so that before starting the step 1 you need to have the destination automatically set to Save to PDF).

Hi Bob, could you please look in to this? It seems that the patch for bug 1662938 didn't fix it.

So, I think this might be related to bug 1663669.
We're overwriting the printer name in the previous printers settings at the moment, which causes some issues with the settings.
Certainly if I apply my WIP patch for that bug, it seems to fix this one.
I think sfoster is going to pick up that bug but I'll check.

It looks settingsAreComplete is still false, and this causes us to show the print dialog (https://searchfox.org/mozilla-central/rev/0c97a6410ff018c22e65a0cbe4e5f2ca4581b22e/layout/printing/nsPrintJob.cpp#669-673)

(In reply to Emma Malysz from comment #7)

It looks settingsAreComplete is still false, and this causes us to show the print dialog (https://searchfox.org/mozilla-central/rev/0c97a6410ff018c22e65a0cbe4e5f2ca4581b22e/layout/printing/nsPrintJob.cpp#669-673)

That's because we were incorrectly updating the printer name.
Once we stop doing that I think this will be fixed.

Can you retest this now that bug 1663669 has landed, please.

Emil is on PTO. Redirecting ni? to Vlad (see comment 10).

Hello,

I have tried to reproduce this issue with 82.0a1(20200919093453) on Windows 10, Ubuntu 20 and macOS 10.14. Used the build from https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=bf7094ba8ae6fcc116bc31caf111620252af7f45, of 1663669 and was unable to encounter it anymore.

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #12)

Hello,

I have tried to reproduce this issue with 82.0a1(20200919093453) on Windows 10, Ubuntu 20 and macOS 10.14. Used the build from https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=bf7094ba8ae6fcc116bc31caf111620252af7f45, of 1663669 and was unable to encounter it anymore.

Thanks, closing as FIXED by bug 1663669.

https://testrail.stage.mozaws.net/index.php?/cases/view/1084698

Hello,
Confirming this issue as verified fixed on macOS 10.15 , Ubuntu 18x64 and Windows 10 with 83.0, 84.0b4 and 85.0a1(2020-11-26).
A variation of this issue has been encountered and a new ticket has been submitted 1679405