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

Steps to reproduce:

print.print_to_filename was set within preferences.json (locked), syspref.js (locked), or manually set in about:config.
"Ctrl + p" to bring up print prompt.
Select print to file.

Actual results:

File save location is either:
When running Firefox within container (zabenno/firefox:full): //mozilla.pdf
When running via apt install on Ubuntu (20|18).04: ~/mozilla.pdf

Expected results:

File save location be the path set within print.print_to_filename preference rather than generated value.

This is a new bug with version 82, version 81 functions correctly.

Hey benc853,

Thanks for reporting this.

Just a add some clarification, this affects the native print dialog on Ubuntu.

I looked into it with mozregression and found this range:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ade89a5867fe41bdd01683b406e1a7d95a3a1e0&tochange=c0f3cbdf8ac5bc018a9d67e5f1c56761a894a66e

Bob, do you think you could take a look to see what may be happening here?

(In reply to Erik Nordin [:nordzilla] from comment #1)

Hey benc853,

Thanks for reporting this.

Just a add some clarification, this affects the native print dialog on Ubuntu.

I looked into it with mozregression and found this range:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ade89a5867fe41bdd01683b406e1a7d95a3a1e0&tochange=c0f3cbdf8ac5bc018a9d67e5f1c56761a894a66e

Bob, do you think you could take a look to see what may be happening here?

My guess is that you need to add nsIPrintSettings::kInitSaveToFileName into those lists of global settings to read.

The severity field is not set for this bug.
:mats, could you have a look please?

For more information, please visit auto_nag documentation.

Erik, do you have cycles to follow up on Bob's comment 2 here?

Yes, I will take a look at this.

Backed out for causing failures on browser_system_dialog_subdialog_hidden.js.

Backout link: https://hg.mozilla.org/integration/autoland/rev/3b68e1da2db1d966f5b7e1da6c2b3ed53661222c

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&searchStr=windows%2C10%2Cx64%2Copt%2Cmochitests%2Ctest-windows10-64%2Fopt-mochitest-browser-chrome-e10s%2Cbc4&revision=f8e28ebbdaa0e6aa34572fff13647450fd34bba7&selectedTaskRun=Iv9SsZkNRXi1p3is2OwuZA.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=326528750&repo=autoland&lineNumber=4561

I am still looking into why these changes would have caused a dialog to be hidden.

The patch that exists attempted to remove a line of front-end code that appeared to be causing this regression.

It took me a while to hunt down this particular line because

1. This functionality broke in multiple places, so mozregression did not locate the only spot that broke the code.
2. The front-end code that appears to cause the regression seems completely unrelated to the behavior that changed.

Given that removing the front-end line of code that fixes this regression ended up causing another issue, I do not necessarily feel like this is the right approach to fix the problem.

Unfortunately, I don't have the cycles right now to dig deeper into the root cause of this issue, and why it's being affected by the front-end code that this patch removes.

Hi,
As per comment 1 I will update "has regression range" field accordingly.
Best,
Clara

Firefox ESR 91 on Debian still ignores "print.printer_Mozilla_Save_to_PDF.print_to_filename" preference and instead offers to save the PDF file named according to the website title directly to the user's home directory.

The "print.printer_Print_to_File.print_to_filename" preference works if one uses the new "Print" interface only to activate the "Print using the system dialog" option (i.e. printer_Print_to_File) to save the PDF. If one uses the new "Print" interface (i.e. printer_Mozilla_Save_to_PDF) to save the PDF the "print.printer_Mozilla_Save_to_PDF.print_to_filename" preference disappears in "about:config". After that the "print.printer_Print_to_File.print_to_filename" preference no longer works although it remains in "about:config".

Is the "print_to_filename" value stored in a way shared by both print dialogs and are values from "print.printer_*.print_to_filename" preferences loaded only once after Firefox or Print dialog starts?

Maybe the inconsistent behavior I noticed could be caused by or related to the following source code part:
https://searchfox.org/mozilla-central/source/toolkit/components/printing/content/print.js#430

I don't know what potentially sensitive info usually appears in website titles and I cannot access the Bug 1675965. But I would sure appreciate if I could force Firefox to not bother with website titles at all when saving printed website as PDF. All I need from Firefox printing is to offer a default filename like "~/SomePath/WebPrint.pdf". Why? Because the website titles are often too long, too inconsistent or even irrelevant and also may contain weird Unicode characters = in short completely unusable/unacceptable source for filenames I prefer on my system.