Bug 1659928 Comment 27 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I can reproduce the blank pages on macOS if I do the following using a build from BEFORE bug 1665904 landed on Sept 20th:

Open Firefox with a new profile, disable the new print UI by setting `print.tab-modal.enabled = false`. (I don't have a way to repro with the new UI yet.)

Additionally add exactly the following four prefs, paying attention to add them with the specified types:

```
user_pref("print.print_paper_size_unit", 1);     // number
user_pref("print.print_paper_name", "iso_a4");   // string
user_pref("print.print_paper_width", "210.00");  // string
user_pref("print.print_paper_width", "297.00");  // string
```

Then print, which opens the system print dialog, and select PDF -> Open in Preview.

We then end up with the value from `print.print_paper_size_unit` being copied onto the equivalent pref for the printer that was selected by default in the system print dialog (so `print.printer_<printer>.print_paper_size_unit`) which is the printer the settings come from for the PDF generation, causing the paper settings for that printer to be busted with the incorrect unit.
I can reproduce the blank pages on macOS if I do the following using a build from BEFORE bug 1665904 landed on Sept 20th:

Open Firefox with a new profile, disable the new print UI by setting `print.tab-modal.enabled = false`. (I don't have a way to repro with the new UI yet.)

Additionally add exactly the following four prefs, paying attention to add them with the specified types:

```
user_pref("print.print_paper_size_unit", 1);     // number
user_pref("print.print_paper_name", "iso_a4");   // string
user_pref("print.print_paper_width", "210.00");  // string
user_pref("print.print_paper_height", "297.00");  // string
```

Then print, which opens the system print dialog, and select PDF -> Open in Preview.

We then end up with the value from `print.print_paper_size_unit` being copied onto the equivalent pref for the printer that was selected by default in the system print dialog (so `print.printer_<printer>.print_paper_size_unit`) which is the printer the settings come from for the PDF generation, causing the paper settings for that printer to be busted with the incorrect unit.
I can reproduce the blank pages on macOS if I do the following using a build from BEFORE bug 1665904 landed on Sept 20th:

Open Firefox with a new profile, disable the new print UI by setting `print.tab-modal.enabled = false`. (I don't have a way to repro with the new UI yet.)

Additionally add exactly the following four prefs, paying attention to add them with the specified types:

```
user_pref("print.print_paper_size_unit", 1);     // number
user_pref("print.print_paper_name", "iso_a4");   // string
user_pref("print.print_paper_width", "210.00");  // string
user_pref("print.print_paper_height", "297.00"); // string
```

Then print, which opens the system print dialog, and select PDF -> Open in Preview.

We then end up with the value from `print.print_paper_size_unit` being copied onto the equivalent pref for the printer that was selected by default in the system print dialog (so `print.printer_<printer>.print_paper_size_unit`) which is the printer the settings come from for the PDF generation, causing the paper settings for that printer to be busted with the incorrect unit.

Back to Bug 1659928 Comment 27