Closed Bug 526811 Opened 15 years ago Closed 2 years ago

Printer dialog will not save/remember settings


(Toolkit :: Printing, defect, P2)

3.5 Branch





(Reporter: singularita, Unassigned)


(Blocks 1 open bug)


User-Agent:       Opera/9.64 (X11; Linux x86_64; U; en) Presto/2.1.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091028 Iceweasel/3.5.4 (Debian-3.5.4-1)

When I want to print a page, the settings are not remembered, so every time I print anything as PDF, I have to choose printer (Print to file), choose format (PDF), choose the directory where to save the output, choose the filename, choose proper paper format, choose a scale and turn off headers and footers to produce correct print. This means about minute of "bureaucracy" before being able to save the page as PDF. Idealy I would like just to change the filename and then press Print.

I think firefox should remember these settings

Reproducible: Always
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.
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
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.
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 / or $name.pdf / $ 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 ?
Depends on: 629500
Version: unspecified → 3.5 Branch
brian_p added the following comment to Launchpad bug report 526482:

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. 

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).
Component: General → Printing
Product: Firefox → Toolkit
Can anyone reproduce this issue on a current Firefox version (23, 24 etc)?

WFM on the latest Nightly (Fx 25).
(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)
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.
Blocks: 947125
Priority: -- → P2
See Also: → 1146814
Summary: Printer dialog will not remember settings → Printer dialog will not save/remember settings

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

That's probably not the whole story though.

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

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

Closed: 2 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.