1682403 - [MacOS] A print orientation "landscape" choice is unexpectedly preserved across printers & print operations, regardless of manual pref-edit/deletion & change in printer

Status: RESOLVED DUPLICATE of bug 1681344

(Core :: Printing: Setup, task)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Start with a fresh profile (or at least clear any about:config prefs that mention print_orientation), and be sure you're using the new tab-modal print dialog (print.tab_modal.enabled set to true)
2. Visit https://example.org and hit Cmd+P to start a print operation.
3. Choose the "Save to PDF" print target, and change the print orientation to landscape, and complete the print-to-PDF operation.
4. Now visit about:config and search for print_orientation, and delete that pref. (It should be named something like print.printer_Mozilla_Save_to_PDF.print_orientation and it'll be set to 1)
5. Repeat step 2, and see what print orientation the dialog ends up using by default.
6. (optional) Choose some other printer in the print dialog, and see what print orientation the dialog suggests for that printer.

ACTUAL RESULTS:
It uses landscape orientation, for Save-to-PDF as well as all other printers that I try, even though I've never printed with the other printers, and even though I deleted the pref that would've saved my prior landscape choice for the PDF printer.

EXPECTED RESULTS:
The print dialog should use portrait orientation for all printers.

Firefox Nightly on MacOS gives ACTUAL RESULTS.
Windows and Linux give EXPECTED RESULTS.

jwatt mentions this might have something to do with this NSPrintInfo sharedPrintInfo object:
https://searchfox.org/mozilla-central/rev/23c25cd32a1e87095301273937b4ee162f41e860/widget/cocoa/nsPrintSettingsX.mm#187-194

(context: I'm semi-blocked on this in bug 1669905 (or need to work with/around it) because over there I need to print to paper in the opposite orientation from what the user selected, e.g. printing to portrait mode with 2 pages per sheet needs to produce a landscape mode page with 2 side-by-side portrait-mode sheets; and I need to be sure that I can undo my under-the-hood switch to landscape mode without inadvertently setting the default for subsequent print operations.)

Comment 1

[Daniel Holbert [:dholbert]]

ALTERNATE STR (expanding on step 6 a little bit):

1. As in comment 0, start with a fresh profile or at least delete all print_orientation prefs.
2. Cmd+P to print, and choose Save to PDF, and choose landscape as your orientation. (and complete the operation)
3. Try to print again, and choose a different print target (i.e. choose a real printer instead of save-to-pdf)

ACTUAL RESULTS:
The new print target uses landscape mode.

EXPECTED RESULTS:
The new print target should still default to portrait mode (even though the save-to-pdf print target preserves its remembered landscape-mode choice).

Firefox Nightly on MacOS gives ACTUAL RESULTS.
Windows and Linux give EXPECTED RESULTS.

Basically, on Mac, it looks like we "super-remember" the orientation between print operations, regardless of pref edits & print-target changes. (Maybe this is true of other configuration options, too; orientation is just a simple one that I happen to be focusing on right now.)

Comment 2

[Daniel Holbert [:dholbert]]

BTW: in my original STR step 4, if I change the pref to 0 instead of deleting it, I still get the same results that I described there (we still use landscape mode, despite the pref explicitly calling for portrait-mode)

So, this isn't just a case of the sharedPrintInfo being used as a "backup" when no pref info is available, or anything like that. Rather, we seem to be ignoring the pref entirely (or maybe we read it but disregard/stomp on it, or something.)

Comment 3

[Daniel Holbert [:dholbert]]

I think I kind of figured out the problem, though it looks like this behavior might be by design, sort of... (But it's ancient, I think, so I don't know that we're tied to it.)

We start out in ReadPrefs (which is called by InitPrintSettingsFromPrefs to set up a print settings object):

nsresult nsPrintSettingsServiceX::ReadPrefs(nsIPrintSettings* aPS, const nsAString& aPrinterName,
                                            uint32_t aFlags) {
  DebugOnly<nsresult> rv = nsPrintSettingsService::ReadPrefs(aPS, aPrinterName, aFlags);
[...]
  Unused << printSettingsX->ReadPageFormatFromPrefs();

https://searchfox.org/mozilla-central/rev/23c25cd32a1e87095301273937b4ee162f41e860/widget/cocoa/nsPrintSettingsServiceX.mm#64

The first quoted line there (invoking the superclass method) simply initializes the nsIPrintSettings object from our saved prefs, doing what I would expect.

BUT, the second quoted line -- printSettingsX->ReadPageFormatFromPrefs() -- stomps on the values that we just initialized from prefs, in CreateOrCopyPrintInfo, with this backtrace:

  * frame #0: `nsPrintSettingsX::CreateOrCopyPrintInfo(this=0x0000000174805e80, aWithScaling=false) at nsPrintSettingsX.mm:198
    frame #1: `nsPrintSettingsX::SetPMPageFormat(this=0x0000000174805e80, aPageFormat=0x00000001747697a0) at nsPrintSettingsX.mm:162
    frame #2: `nsPrintSettingsX::ReadPageFormatFromPrefs(this=0x0000000174805e80) at nsPrintSettingsX.mm:87
    frame #3: `nsPrintSettingsServiceX::ReadPrefs(this=0x00000001403c4c40, aPS=0x0000000174805e80, aPrinterName=u"", aFlags=134447230) at nsPrintSettingsServiceX.mm:65
    frame #4: `nsPrintSettingsService::InitPrintSettingsFromPrefs(this=0x00000001403c4c40, aPS=0x0000000174805e80, aUsePNP=false, aFlags=134447230) at nsPrintSettingsService.cpp:868

This CreateOrCopyPrintInfo function reads data from the sharedPrintInfo noted in comment 0 here (jwatt was right!) -- and this is data that we saved in our last print operation, it seems.

I had a suspicion that this behavior might be aiming to match some sort of MacOS-specific convention to remember user-entered data between print operations regardless of printer, but that doesn't seem to be the case. In fact: if I print from Safari and choose Landscape mode, Safari does not remember my landscape-orientation choice for the subsequent print operation, even if I keep the printer choice the same.

Comment 4

[Daniel Holbert [:dholbert]]

The core issue in comment 3 seems to date back to Jan 2007 where these cocoa print-settings files were first added to the tree:
https://searchfox.org/mozilla-central/commit/5d473d4dc67b8e276d688a72a358a5646e9fe2bc

(It's probably older than that, since the commit message there is "copy printing impl to cocoa widgets")

Here's a highlighted version of the ReadPrefs function as of that point -- it shows basically the same problematic two-line sequence that I quoted in comment 3 (initializing by reading from prefs, and then stomping on the just-read values with a different data-reading function-call, effectively disregarding some of the prefs):
https://searchfox.org/mozilla-central/rev/5d473d4dc67b8e276d688a72a358a5646e9fe2bc/widget/src/cocoa/nsPrintOptionsX.mm#112,118

Comment 5

[Jonathan Kew [:jfkthame]]

Not sure how soon I'll get time to test this, but based on the comments above, I wonder if the patch in bug 1681344 will (fortuitously) fix this, as it eliminates the storage of a serialized PMPageFormat in prefs?

Comment 6

[Daniel Holbert [:dholbert]]

Thanks -- I just tested the patch in bug 1681344, and indeed it does fix this! (the "same printer with pref deleted" scenario from comment 0, as well as the "switch printer" scenario from comment 1)

I'll dupe this over to that bug.