Firefox don't save print settings

[Dimitar Angelov]

Binary package hint: firefox

Environment:
OS: Ubuntu 9.10 (Karmic Koala)
Package: firefox-3.5 (3.5.8+build1+nobinonly-0ubuntu0.9.10.1)
Problem:
I print from firefox and change print settings, like select destination printer, margins, header, footer and so on. In about:config option 'print.save_print_settings' is set to true. Finally do print.
Immediately after previous print I do print again and I suspect to get same settings (destination printer, margins, header, footer ...) that I set for last print, but unfortunately I get default print settings (destination printer, margins, header, footer ...).
All this is happen in same browser session.
Problem also reflect on our extension that we developed for Firefox (jsPrintSetup https://addons.mozilla.org/en-US/firefox/addon/8966).
The extension using nsIPrintSettings interface to manage print settings also encounter problem with select destination printer.
Independently from selected nsIPrintSettings.printerName Firefox always print to default for operating system printer.

[Otto Kekäläinen (otto)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fi; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Gecko/20100106 Ubuntu/9.10 Firefox/3.5.7

The Mozilla/Firefox print dialog does not seem to work like the print
dialog in other Gnome applications:

Example:
1. In Firefox, the default file type is PostScript, while in Gedit it is PDF.
(bug #539426)
2. In Firefox the default file name is empty ".ps", while in Gedit it is
"print.pdf". (bug #485067)
3. In Firefox, the print dialog does not remember any settings unlike the
dialog in Gedit. If you for example choose in the Firefox dialog to make a
two-sided print, nothing of it is left when you restart Firefox. In Gedit every
change to any optio is saved - if you once choose to e.g. make a two-sided
print, all prints will be two-sided until the option is changed again.
4. The file dialog does not remember the folder last used (bug #454003)

In my opinion Firefox should implement the print dialog in the same way as
other Gnome/GTK apps do. The behaviour of e.g. Gedit is more correct and closer
to the principles for example described in the Gnome User Interface Guidelines.

Also I read the original Netscape's philosophy was "keep each dialog in the
same state where it was last time".

Reproducible: Always

[Dimitar Angelov (mitko-edabg)]

Binary package hint: firefox

Environment:
OS: Ubuntu 9.10 (Karmic Koala)
Package: firefox-3.5 (3.5.8+build1+nobinonly-0ubuntu0.9.10.1)
Problem:
I print from firefox and change print settings, like select destination printer, margins, header, footer and so on. In about:config option 'print.save_print_settings' is set to true. Finally do print.
Immediately after previous print I do print again and I suspect to get same settings (destination printer, margins, header, footer ...) that I set for last print, but unfortunately I get default print settings (destination printer, margins, header, footer ...).
All this is happen in same browser session.
Problem also reflect on our extension that we developed for Firefox (jsPrintSetup https://addons.mozilla.org/en-US/firefox/addon/8966).
The extension using nsIPrintSettings interface to manage print settings also encounter problem with select destination printer.
Independently from selected nsIPrintSettings.printerName Firefox always print to default for operating system printer.

[Suseuser04 (suseuser04)]

Firefox does not remember many of the print settings the user has set.
Eg.:

1. When printing, image quality resolution is always set to 300 dpi, can't remember any other value, even in one session.

2. Firefox can't remember header/footer settings if the page is printed to file (pdf or ps).

3. Firefox can't remember the directory where the last 'print to file' (pdf or ps file) page was saved/printed.

4. When using print to file, existing file (pdf or ps) can't be selected for renaming, which makes naming the new file very cumbersome.

[Robert Hrovat (robi-hipnos)]

More info:
https://support.mozilla.com/en-US/forum/1/547037
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/250140

So this bug was first reported with 3.0 and is still present in latest versions. It really should be fixed.

[TH (thaugseth)]

I can confirm this.

My biggest problem is that the dialog don't remember the resolution when printing to a normal printer. It always defaults to 300x300 DRAFT, which results in extremely poor quality on paper.

I've set the default resolution in Gnome -> System -> Administration -> Printing -> Printer Options -> Resolution to 600x600, but this is not respected by Firefox.

[TH (thaugseth)]

I can confirm this, and have linked an upstream bug report.

[Swedishchef79 (swedishchef79)]

SeaMonkey (tested with 2.0.5) is also affected by this. But I've found some interesting difference between my Debian Lenny and Squeeze machines:

On Lenny, SeaMonkey (and Iceweasel 3.0.x) do not save settings, but they at least respect the CUPS default settings. Settings CUPS to 600dpi results in 600dpi in the print dialog.

On Squeeze, SeaMonkey (and Iceweasel 3.5.x) do not save settings, *and* they *ignore* the CUPS default settings. Although CUPS is set to 600dpi, the print dialog always defaults to 300dpi.

It doesn't even remember it for the current session, the settings are reset every time you open the print dialog.

Hopefully this information is of any use.

[Robert Hrovat (robi-hipnos)]

It looks like it depends on drivers. My Kyocera FS-1030D printer has 2 possible drivers. The Foomatic and manufacturer PPD. With Foomatic it defaults to High Quality print mode, while it defaults to drafts with manufacturer supplied PPD.

[Bzbarsky (bzbarsky)]

roc, do you know who owns this UI?

[Daniel Holbert (dholbert)]

I think ventron worked on this UI most recently. Haven't seen him on IRC recently, though, so I'm not sure if he's still around.

See also possibly-related bug 446041 & bug 464985.

[Daniel Holbert (dholbert)]

Yeah, I think this is the same as bug 446041. (bug 446041 comment 5 mentions some other duplicates, too)

[areteichi (areteichi)]

I have the same problem with Firefox 3.6.6 under Ubuntu 10.04, although I've been experiencing this for quite some time.
I have two problems: the page size reverts back to 'US Letter' even after I select 'A4', and header and footer choices revert back to default. Please fix this problem soon as this issue has persisted a long time.

[darkenergy (darkenergy)]

i can confirm this!

even if you see for example that you have in about:config for a given printer different settings saved, it takes the default values.

very annoying!

[Foxfire (foxfire)]

I'm suffering this annoying problem and from Googling to try to find a solution, it seems that it's something a hell of a lot of people are annoyed about.

My system defaults are correct:
---------------------------------------------------
$ lpoptions -l
PageSize/Media Size: Letter Legal Executive *A4 A5 A6 Env10 EnvMonarch EnvDL EnvC5 EnvISOB5 EnvISOB6
BrMediaType/BrMediaType: *PLAIN THIN THICK THICKERPAPER2 BOND TRANSPARENCIES ENV ENVTHICK ENVTHIN
InputSlot/InputSlot: MANUAL *TRAY1
Resolution/Resolution: 300dpi 600dpi *1200x600dpi
TonerSaveMode/Toner Save: *Off On
Sleep/Sleep Time [Min.]: *PrinterDefault 2minutes 10minutes 30minutes
----------------------------------------------------
but whatever I do, Firefox insists on defaulting to 300dpi

On some forums it's been suggested that changing print.save_print_settings to "true" in about:config might help, but unfortunately it doesn't.

[Alan Lord (theopensourcerer)]

This has been going on for ages. As an Ubuntu user I thought it was restricted to Gnome but it also appears to be effective on Windows: Bug 516550 and Macs: 533889.

The *really* annoying bit for me is paper size. I'm in the UK and we use A4 paper for general printing. Virtually every time I need to print something the settings have reverted back to default of US Letter. This stops my printer from printing whilst it waits for me to add US Letter sized paper or tell the printer to print anyway.

This has been occurring on many different printers for several years now.

On Launchpad, there are several bug reports about this and they date back to 2004! For example: https://bugs.launchpad.net/firefox/+bug/10910

This also affects Thunderbird too.

Why is this bug still marked as UNCONFIRMED?

[Daniel Holbert (dholbert)]

(In reply to comment #8)
> Why is this bug still marked as UNCONFIRMED?

Because it's best not to confirm a bug if it's actually a duplicate, and no one's taken the time to establish whether this is a duplicate (per comment 7) or a separate bug yet.

I'm pretty sure it's a duplicate, though, so I'm marking it as such.

*** This bug has been marked as a duplicate of bug 446041 ***

[Suseuser04 (suseuser04)]

Daniel,
I dont'see why would this bug report be a duplicate of 446041.
For example I have only one printer configured which is the default printer and its resolution is set to 600 dpi. Firefox still insists to 300 dpi when I want to print with this only one default printer. Furthermore 446041 regards to margin settings, this one reports different things, like default file type and name when printing to file, footer and header settings are not remembered when printing to file. Why is it a duplicate of a bug related to margin settings?

I don't deny that they might be related and that there aren't other bug reports with similar/same issues. This rises the question how come these problems still exist after these years.

[Daniel Holbert (dholbert)]

(In reply to comment #10)
> For example I have only one printer configured which is the default printer and
> its resolution is set to 600 dpi. Firefox still insists to 300 dpi when I want
> to print with this only one default printer.

Valid point -- ok, probably not quite the same bug then. Reopening this bug.

> Furthermore 446041 regards to
> margin settings, this one reports different things, like default file type and
> name when printing to file, footer and header settings are not remembered when
> printing to file. Why is it a duplicate of a bug related to margin settings?

The other bug just happened to use margin settings as an example, but it applies to other printer settings too. (Printer settings are generally all stored in about:config in the same way.)

[jpfle (jpfle)]

Is this report a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=526811 ?

[areteichi (areteichi)]

Finally this bug is receiving some attention? Still experiencing this with 3.6.10.
I hope this gets fixed soon!

[dysmann (dysmann)]

The problem still exists with the latest Firefox trunk. This is very annoying when you have to test printing to a PDF file many times in order to get a perfect result (as a web developer and maybe as user too).

I 100% agree with B.H., with the filename being filled by default with the page filename without extension or the latest used one. This would save o lot of time when testing.

I would also add (imho) :
 - PDF should be the default instead of PS, since I think PDF is much more convenient as a portable format
 - The default name should not be ".pdf" or ".ps", but rather out.pdf / out.ps or $name.pdf / $name.ps where $name is the page filename without the extension. This seems cleaner and doesn't give an hidden file.
 - The latest used printer should be pre-selected, even if the printer is "Print to a file" (I'm using Ubuntu). If there is only one choice (one printer), no need to ask the use to choose, just select it by default.

Should I post a new bug report for these last ideas ?

[brian_p (claremont102)]

With CUPS and *some* drivers Firefox honours all the print queue parameters *except* resolution. It initially offers 300dpi irregardless of the queue settings and without lpoptions being invoked on the client machine. I am not concerned with the setting sticking if changed by a user as I believe the only sticky setting should be the one which Firefox has got from

   lpoptions <printer_queue> -l

It knows what it is but for some reason it insists that the queue resolution must be 300dpi in spite of being informed it is something else like 600dpi. It is not even consistent in its view because it only does this with some drivers.

Why? The ppd produced by the CUPS+Gutenprint v6.2.6 has the line

  *Resolution 300dpi/300x300 DPI: "<</HWResolution[300 300]/cupsCompression 3>>setpagedevice"

Change 300dpi to 301dpi or 300dp or 300x300dpi. Now the Firefox print dialogue displays the correct queue resolution.

Firefox has no problem with the Foomatic/pixmono (en) driver. If a queue is 150dpi in resolution Firefox displays that. No defaulting to 300dpi in this case. Its ppd has

  *PrinterResolution 300x300dpi/300 DPI: "%% FoomaticRIPOptionSetting: PrinterResolution=300x300dpi"

Note the difference in the format.

My theory is Firefox looks for 300dpi and defaults to that value if it is found. If not found it displays the queue value it already knows. It should stop doing this.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[mocho (mochoandre)]

Still going on this bug

[Lx-guillaume-i1 (lx-guillaume-i1)]

I'm also affected by the PrinterResolution setting not being remembered neither using the CUPS printer setting.
Using Firefox 1.0.11 (latest stable/ESR version distributed by Debian GNU/Linux as Iceweasel 1.0.11).

That's very annoying, plus with the 300 dpi setting selected by Firefox, printing often fail for me (that failure is probably another cups/driver bug, but linked with this settings bug, that make it so much more annoying).

[Jhorak (jhorak)]

Created attachment 729488
Save resolution (dpi) and duplex settings v1

I've made patch which adds support of saving print resolution and duplex settings to preferences. It saves these preferences only when they are available to selected printer.

[Daniel Holbert (dholbert)]

Comment on attachment 729488
Save resolution (dpi) and duplex settings v1

I think this patch generally makes sense. Looks like this is just two pieces of data that are configurable in the print dialog, which we don't currently save between print jobs, but which we easily can by storing them in about:config like we do for other data. (and that's what the patch does)

This probably needs review from roc or karlt, the Widget:GTK module owner / peer. (Or someone who's actively working on printing, but unfortunately there have been very few people in that category recently. :))

Feedback below:

># HG changeset patch
># Parent fd5463b65693b5808cd3cde19f8d4c9d0a2c199b
># User Jan Horak <email address hidden>
># Bug #539427 - The Print dialog does not remember any settings, unlike other Gnome/GTK apps
># This patch saves print resolution (dpi) and duplex settings (two sided printing). It only
># stores settings only if the settings is available for printer.

Mozilla commit message convention to describe the change, not the bug, and if possible keep it all on one line (since our RelEng infrastructure generally only prints the first line).

So -- this should look like:
> Bug 539427: Save print resolution (DPI) and duplex settings between print jobs, if they're available.
or something along those lines.

>diff --git a/widget/gtk2/nsPrintSettingsGTK.cpp b/widget/gtk2/nsPrintSettingsGTK.cpp
[...]
>+NS_IMETHODIMP
>+nsPrintSettingsGTK::GetResolution(int32_t *aResolution)

Remove space-at-end-of-line after "NS_IMETHODIMP" here (and in all of your other added "NS_IMETHODIMP" lines in this file.)

>+nsPrintSettingsGTK::GetDuplex(int32_t *aDuplex)
>+{
>+ if (!gtk_print_settings_has_key(mPrintSettings, GTK_PRINT_SETTINGS_DUPLEX))
>+ return NS_ERROR_FAILURE;
>+ *aDuplex = (int16_t) gtk_print_settings_get_duplex(mPrintSettings);
>+ return NS_OK;

Why cast to int16_t here? The outparam is int32_t, not int16_t.

Also: use static_cast, not a c-style cast.

>+NS_IMETHODIMP
>+nsPrintSettingsGTK::SetDuplex(int32_t aDuplex)
>+{
>+ gtk_print_settings_set_duplex(mPrintSettings, (GtkPrintDuplex) aDuplex);

Use a static_cast instead of C-style cast.

Also: assert that we're in-range for a GtkPrintDuplex before doing this cast. e.g.:
 MOZ_ASSERT(aDuplex >= GTK_PRINT_DUPLEX_SIMPLEX &&
            aDuplex <= GTK_PRINT_DUPLEX_VERTICAL,
            "value is out of bounds for GtkPrintDuplex enum");

>@@ -244,16 +244,20 @@ interface nsIPrintSettings : nsISupports
> attribute long printPageDelay; /* in milliseconds */
>
>+ attribute long resolution; /* print resolution (dpi) */
>+
>+ attribute long duplex; /* print in duplex or simplex mode */
>+
  ^^ Drop the 2 space characters on this blank line here.

Also: that last comment makes it sound like "duplex" is a boolean value -- but it's not. (There are 3 possibilities, not 2.)
Maybe replace that comment with just "/* duplex mode */"?

[Daniel Holbert (dholbert)]

[I'm narrowing the scope of the bug-summary to be more specific & cover what the attached patch actually addresses. I believe the rest of comment 0 is already covered in other bugs (or can be tracked in a new bug)].

[Jhorak (jhorak)]

Created attachment 730597
Save resolution (dpi) and duplex settings v2

Thanks for feedback, asking roc for review of fixed patch.

[Jhorak (jhorak)]

Do I need superreview while changing idl file before it can be checked in?

[R-bugs-h (r-bugs-h)]

Comment on attachment 730597
Save resolution (dpi) and duplex settings v2

update uuid of the nsIPrintSettings interface.

[Daniel Holbert (dholbert)]

(To be clear, Olli is pointing out that you need to update the hexadecimal UUID here to a new randomly-generated UUID:
  https://mxr.mozilla.org/mozilla-central/source/widget/nsIPrintSettings.idl#25
since the interface is changing. Sorry, I should've caught that when I first looked at this.)

There's a variety of ways to generate UUIDs; one easy way is to just say "firebot, uuid" on irc.mozilla.org. (by e.g. visiting http://irc.lc/mozilla/firebot/yourIRCUsername)

[R-bugs-h (r-bugs-h)]

http://mozilla.pettay.fi/cgi-bin/mozuuid.pl gives a new uuid
(and it gives also C++ form, in case you need it. But for this patch the normal single line uuid is enough)

[Jhorak (jhorak)]

Created attachment 732297
Save uri for downloaded files patch v3

Thanks, I'm aware of changing uuid when idl is changing but I forgot to do it, sorry guys.

Attaching patch with fixed uuid, copying review and superreview from previous comments.

[Ryanvm (ryanvm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b6612169995a

[Ryanvm (ryanvm)]

Backed out for build bustage. Please make sure your patch compiles before requesting checkin...
https://hg.mozilla.org/integration/mozilla-inbound/rev/bfcd471a1ed9

https://tbpl.mozilla.org/php/getParsedLog.php?id=21680095&tree=Mozilla-Inbound

../../../../widget/xpwidgets/nsPrintOptionsImpl.cpp:498:34: error: no member named 'kInitSaveResolution' in 'nsIPrintSettings'; did you mean 'kInitSaveResolutionName'?
  if (aFlags & nsIPrintSettings::kInitSaveResolution) {
               ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
                                 kInitSaveResolutionName
../../dist/include/nsIPrintSettings.h:62:5: note: 'kInitSaveResolutionName' declared here
    kInitSaveResolutionName = 1073741824U,
    ^
../../../../widget/xpwidgets/nsPrintOptionsImpl.cpp:505:34: error: no member named 'kInitSaveDuplex' in 'nsIPrintSettings'
  if (aFlags & nsIPrintSettings::kInitSaveDuplex) {
               ~~~~~~~~~~~~~~~~~~^
../../../../widget/xpwidgets/nsPrintOptionsImpl.cpp:808:34: error: no member named 'kInitSaveResolution' in 'nsIPrintSettings'; did you mean 'kInitSaveResolutionName'?
  if (aFlags & nsIPrintSettings::kInitSaveResolution) {
               ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
                                 kInitSaveResolutionName
../../dist/include/nsIPrintSettings.h:62:5: note: 'kInitSaveResolutionName' declared here
    kInitSaveResolutionName = 1073741824U,
    ^
../../../../widget/xpwidgets/nsPrintOptionsImpl.cpp:815:34: error: no member named 'kInitSaveDuplex' in 'nsIPrintSettings'
  if (aFlags & nsIPrintSettings::kInitSaveDuplex) {
               ~~~~~~~~~~~~~~~~~~^
4 errors generated.
make[7]: *** [nsPrintOptionsImpl.o] Error 1

[Jhorak (jhorak)]

Created attachment 736256
Save resolution (dpi) and duplex settings v4

Hmm, strange, looks like part:
  const unsigned long kInitSaveResolution = 0x00000400;
  const unsigned long kInitSaveDuplex = 0x00000800;
disappeared from patch during checkin somehow, maybe bitrotten patch? I'm sorry about difficulties. Attaching fresh patch against today sources.

[Ryanvm (ryanvm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2bb26d742f5f

[Ryanvm (ryanvm)]

https://hg.mozilla.org/mozilla-central/rev/2bb26d742f5f

[Ioana-budnar (ioana-budnar)]

Can anyone reproduce this issue on a current Firefox version (23, 24 etc)?

WFM on the latest Nightly (Fx 25).

[Foxfire-k (foxfire-k)]

(In reply to Ioana Budnar, QA [:ioana] from comment #6)
> Can anyone reproduce this issue on a current Firefox version (23, 24 etc)?
>
> WFM on the latest Nightly (Fx 25).

Still a problem for me (Beta channel, Firefox 23.0, last update 20/07/2013)

[Raphaël Jakse (raphael-jakse)]

Works for me on the latest Nighlty. However, while remembering the folder used to save (if I print in a file, the file is stored in the folder I used the last time), the print dialog doesn't shows this folder: the drop down list for choosing the folder shows nothing (empty string) instead.

Doesn't work in Firefox 22.

[Jonathan Watt (jwatt)]

Possibly related is that nsPrintSettingsService::GetGlobalPrintSettings and nsPrintSettingsService::GetNewPrintSettings essentially do the same thing:

https://searchfox.org/mozilla-central/rev/8b7aa8af652f87d39349067a5bc9c0256bf6dedc/widget/nsPrintSettingsService.cpp#927

That's probably not the whole story though.

[Release-mgmt-account-bot (release-mgmt-account-bot)]

In the process of [migrating remaining bugs to the new severity system](https://bugzilla.mozilla.org/show_bug.cgi?id=1789259), the severity for this bug cannot be automatically determined. Please retriage this bug using the [new severity system](https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity).

[Mstriemer (mstriemer)]

No real activity in several years here. Feel free to reopen with more info if this is still reproducing