1319116 - firefox print settings for header and footer not remembered

Status: RESOLVED FIXED

(Core :: Printing: Setup, defect, P1)

Description

[steve]

Attachment: firefox print settings.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161104212021

Steps to reproduce:

Print articles to PDF with Firefox:

1. visit an article e.g. https://www.heise.de/newsticker/meldung/Internetueberwachung-Amnesty-klagt-gegen-BND-Datenstaubsauger-3466588.html?view=print
2. ⌘P to open print dialog
3. clear all header and footer options to empty (in german locale that translates to --leer--)
4. save to PDF (via the dropdown selection in the bottom left - it shows 'PDF' in the screenshot)
5. after the PDF is stored the print dialog closes
6. ⌘P to open another print dialog


Actual results:

All header + footer options are filled again.


Expected results:

The header + footer options should be remembered.

The user just set them to a certain value. Chances are the user prefers that specific value for their use case. So it would be best, if Firefox respected that choice and remembered those adjustments.

Does that make sense?

I found several bugs regarding such issues, but opted to file a new one to start clean.

Existing similar bugs where:
- https://bugzilla.mozilla.org/show_bug.cgi?id=526811 (file in 2009 and still unconfirmed!)
- https://bugzilla.mozilla.org/show_bug.cgi?id=1136855 (fixed)
- https://bugzilla.mozilla.org/show_bug.cgi?id=242134 (worksforme)

Comment 1

[Bob Owen (:bobowen)]

This seems familiar is it a duplicate?

Comment 2

[Haik Aftandilian [:haik]]

I couldn't find a dupe that's still open. Fixing bug 1303051 made the print dialog remember paper size, orientation, and scaling percentage, (and respect those settings when doing a print) but we need to do a little more work on the Mac Print dialog. Been meaning to file a new bug with some of the issues I found, but this bug would work. Here are some other things to fix.

1) In addition to what's reported here, the Ignore Scaling and Shrink To Fit Page Width checkbox, Print Background Colors, and Print Background Images are not persisted.

2) The Frames print options probably aren't persisted.

3) The scaling percentage should be grayed out / inactive unless "Ignore Scaling and Shrink To Fit Page Width" is checked.

Comment 3

[steve]

Is anything missing to move this out of unconfirmed? Looking at comment 2 this sounds a lot like confirmed.

Comment 6

[Haik Aftandilian [:haik]]

Needinfo for myself to look into a fix for the header/footer issue.

Comment 7

[steve]

Re: sounding familiar: this ones similar but not identical:
https://bugzilla.mozilla.org/show_bug.cgi?id=526811

Also thanks a lot for assigning this and making it a P1 item. Highly appreciated.

Comment 8

[steve]

@Haik, was there any progress on this bug?

Comment 9

[Haik Aftandilian [:haik]]

(In reply to steve-_- from comment #8)

@Haik, was there any progress on this bug?

Sorry, I haven't been able to find time to work on this. I'm going to leave the needinfo here and will try to prioritize this for 67.

Comment 10

[Haik Aftandilian [:haik]]

Still working on this, but so far I can see that when we display the print dialog, we fill the header/footer settings with values read from prefs that are not printer-specific:

print.print_footerleft
print.print_footercenter
print.print_footerright

print.print_headerleft
print.print_headercenter
print.print_headerright

Then, after we print the document, we save the header/footer settings to printer-specific prefs so they are tied to the selected printer. Here's an example where the printer is "HP InkJet".

print.printer_HP_InkJet.print_footerleft
print.printer_HP_InkJet.print_footercenter
print.printer_HP_InkJet.print_footerright

print.printer_HP_InkJet.print_headerleft
print.printer_HP_InkJet.print_headercenter
print.printer_HP_InkJet.print_headerright

For a fix, we should either make the head/footer settings not be tied to a printer, or fix the code so we load the print dialog with the settings associated with the current printer.

Comment 11

[Haik Aftandilian [:haik]]

As a workaround until we have the bug fixed, one could set the default header/footer prefs to different values. Changes still will not persist and be reflected in the next print operation, but the print dialog will always start with these values.

To try that workaround, edit the following header/footer prefs setting them to either nothing (an empty string) or one of &T, &U, &D, &P, or &PT (explained below.) For example, to make the header and footer empty, set them all to the empty string.

print.print_footerleft
print.print_footercenter
print.print_footerright

print.print_headerleft
print.print_headercenter
print.print_headerright

Print header customization:
Set each header to a string containing zero or one of these codes
and the code will be replaced in that string by the corresponding data.

• &T - Title
• &U - Document URL
• &D - Date/Time
• &P - Page Number
• &PT - Page Number "of" Page total

Comment 12

[Andy Bajka]

Hi Haik,

I think Firefox needs to eliminate these two things:

1. File -> Page Setup...
2. File -> Print -> Page Headers and Page Footers

Then please look at the Print user interface in Chrome. It shows how the printed page will look like, this is a very nice feature and one that I would like to see in Firefox.

Thank you.

Comment 13

[Haik Aftandilian [:haik]]

Hi Andy,

(In reply to Andy Bajka from comment #12)

Hi Haik,

I think Firefox needs to eliminate these two things:

1. File -> Page Setup...

I agree. We have bug 1492299 filed for that, but we haven't done any work on it. It would be great if you can comment on the bug with your opinion about it.

2. File -> Print -> Page Headers and Page Footers

I think having the ability to customize the headers/footers is useful, but maybe we only need to enable/disable printing them. We would want to get some data first about how much the settings are used before removing them.

Then please look at the Print user interface in Chrome. It shows how the printed page will look like, this is a very nice feature and one that I would like to see in Firefox.

Thanks for the feedback. I agree and I think the preview would be a nice improvement on Mac. On Windows, we do have a preview via page setup. I looked back through some old bugs, searching for "mac print preview" and some bugs have been filed over the years to add this, but it never got done.

With this bug, I just want to fix the header/footer setting persistence issue.

Comment 14

[Haik Aftandilian [:haik]]

Attachment: Bug 1319116 - firefox print settings for header and footer not remembered

Comment 15

[Haik Aftandilian [:haik]]

Attachment: Bug 1319116 - Part 1 - Firefox print settings for header and footer not remembered r?jwatt

Load the saved printer-specific settings prefs before displaying the print dialog.

PrintSettings received from sandboxed content processes do not include the printer name because access to the printer server is blocked by sandboxing.

Comment 16

[Haik Aftandilian [:haik]]

Attachment: Bug 1319116 - Part 2 - "Cancel" reverts header and footer settings to defaults r?jwatt

On Mac, don't attempt to save print settings after the user cancels out of the print dialog.

Depends on D23888

Comment 17

[Haik Aftandilian [:haik]]

After a successful print operation, the printing code was correctly saving the header and footer settings to printer-specific preferences. But, for a new print operation, those printer-specific prefs were not being loaded to populate the print dialog. When printing, the child process creates and fills a print settings object and sends it over to the parent process. Most of the fields sent from the child process are ignored because with remote printing and process sandboxing, the child process does not have access to the system print server and can't fill in the printer name. The parent process reads printer settings from preferences, but due to the printer settings not having the correct printer name (just the empty string), the settings saved for the printer are not loaded, only the defaults are loaded. (Printer-specific settings are saved in prefs using the printer name.)

After fixing the print dialog code in the parent to load the printer-specific prefs using the correct printer name, I noticed that after cancelling out of the print dialog, the header/footer settings were reverted back to the browser defaults. Normally, after a print operation, the saving of settings is triggered by the child process sending a request to the parent to save printer settings: after a print, the parent process sends back the updated print settings data. Then the child sends the data back to the parent to be saved in prefs. However, on a cancelled print, we throwaway the print settings data that was used to display the print dialog. But the child process still requests the print settings to be saved and as a result, we save default settings. This is due to the parent process, after constructing a correct print settings object, not serializing that updated print settings object for sending it back to the child on a cancelled print.

Comment 18

[Andy Bajka]

Hi Haik,

In earlier posts in this bug thread, I thought we already established that the Page Setup, Page Headers and Page Footers should be eliminated. Neither Chrome or Safari have such functions and I think these three things serve only to make using Firefox confusing. Please look into eliminating these three functions.

Comment 19

[Haik Aftandilian [:haik]]

(In reply to Andy Bajka from comment #18)

Hi Haik,

In earlier posts in this bug thread, I thought we already established that the Page Setup, Page Headers and Page Footers should be eliminated. Neither Chrome or Safari have such functions and I think these three things serve only to make using Firefox confusing. Please look into eliminating these three functions.

Yes, I think Page Setup should be removed (in bug 1492299).

Regarding removing the header/footer section for simplification, keep in mind that the options for header/footer are only displayed in the "Show Details" section of the print dialog.

And yes I do agree that a print dialog with preview (like Chrome and Safari) is definitely something we should do, but that doesn't mean we shouldn't fix this bug in the meantime. Would you like to file a bug for adding the print dialog preview? I can't say when or if the bug will be worked on because it has to be prioritized accordingly.

From searching bugzilla, I see old references to print preview functionality for Mac. I'm not sure what the history is here or how we used to implement it. Jonathan, any chance you're familiar with our past efforts for a Mac print preview?

Comment 20

[Andy Bajka]

Please add the print dialog with preview (like Chrome and Safari).

Regarding the header/footer function, yes I'm aware these are located in the Print dialog. I think they should be removed for the following reason:

1. They confuse people.
2. They add text to the final print which most don't want or need.
3. They don't work properly as in the case of wanting to eliminate them.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4facacafeb00
Part 1 - Firefox print settings for header and footer not remembered r=jwatt
https://hg.mozilla.org/integration/autoland/rev/e22b717c6308
Part 2 - "Cancel" reverts header and footer settings to defaults r=jwatt

Comment 22

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/4facacafeb00
https://hg.mozilla.org/mozilla-central/rev/e22b717c6308

Comment 23

[steve]

Thanks so much for addressing this. Further outstanding print dialog issues/enhancements should probably be dealt with in other new / existing bugs.