This only happens if the pref
print_printer isn't set (i.e. the user has never printed before).
This is yet another issue related to how the legacy printing code in the parent process "passes" settings to PrintingChild.jsm in the contend process by saving them to prefs before messaging PrintingChild.jsm. Prior to the "Front-end tweaks" patch, if
print_printer wasn't set then the settings to pass were saved to prefs without a printer prefix in the pref names. That matches up with what getPrintSettings in PrintingChild.jsm, since if
print_printer is unset it reads from the unprefixed prefs.
The "Front-end tweaks" patch made the frontend code use and save to prefs prefixed with the system default printer if
print_printer is not set. Hence why the code in PrintingChild.jsm isn't picking them up.
We can't really make the content process do the same thing with nsIPrinterList to get the system default printer, since that conflicts with what we want to do with sandboxing.
We could revert the change to printPageSetup.js to go back to just using
gPrintService.lastUsedPrinterName blindly as it did before. But that actually doesn't work as of bug 1667953, which has been uplifted to v82b6. That bug makes us stop picking up most print settings from unprefixed prefs to avoid the misbehavior we've seen in multiple bug reports when settings incompatible with a given printer have made it into the unprefixed prefs and get picked up for that printer.
Maybe the most pragmatic way forward is, if
print_printer is unset, have the code that opens print preview get the printer in the same way as the code added to printPageSetup.js, get its default settings, save them to prefs as the "last used" printer, then proceed as normal.