1668621 - Setting custom print margins no longer works for users who haven't printed before, as of v81

Status: RESOLVED DUPLICATE of bug 1669187

(Toolkit :: Printing, defect, P1)

Description

[Jonathan Watt [:jwatt]]

Filing this for https://support.mozilla.org/en-US/questions/1306689

On Widows, open the old print preview, click "Page Setup..." button, then select the "Margins & Header/Footer" tab, change one of the margin and click "OK".

Prior to v81 this would update the margins shown in the preview.

I ran mozregression and came up with the following regression range:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d1de0bdfee4fcc742faa7126c9c4d1c18d89bfe3&tochange=527908cfaa564c8075855b0d42aa2dad761d5444

The only bug in there that looks like it could have caused this is bug 1657363. I.e.:

https://hg.mozilla.org/integration/autoland/rev/110aeee7685afb52f91195141e00629420dbf850
https://hg.mozilla.org/integration/autoland/rev/f20f7b4160630866b3292f1e8b831404d45dff87

Comment 1

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

Set release status flags based on info from the regressing bug 1657363

Comment 2

[Jonathan Watt [:jwatt]]

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.

Comment 5

[Jonathan Watt [:jwatt]]

The patch for bug 1669187 fixes this, at least to the extent we can without taking on too much risk.