539427 - Print dialog does not remember duplex or DPI settings between print jobs

Status: RESOLVED FIXED

(Core :: Printing: Setup, defect)

Description

[Otto Kekäläinen]

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

Comment 1

[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.

Comment 2

[Robert]

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.

Comment 3

[u347682]

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.

Comment 4

[Robert]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

roc, do you know who owns this UI?

Comment 6

[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.

Comment 7

[Daniel Holbert [:dholbert]]

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

Comment 8

[lord_alan]

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?

Comment 9

[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.

Comment 10

[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.

Comment 11

[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.)

Comment 12

[Jean-Philippe Fleury]

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

Comment 13

[Launchpad]

mocho added the following comment to Launchpad bug report 526482:

Still going on this bug


-- 
http://launchpad.net/bugs/526482

Comment 14

[Jan Horak [:jhorak]]

Attachment: 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.

Comment 15

[Daniel Holbert [:dholbert]]

Comment on attachment 729488 [details] [diff] [review]
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 <[e-mail]>
># 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 */"?

Comment 16

[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)].

Comment 17

[Jan Horak [:jhorak]]

Attachment: Save resolution (dpi) and duplex settings v2

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

Comment 18

[Jan Horak [:jhorak]]

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

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 730597 [details] [diff] [review]
Save resolution (dpi) and duplex settings v2

update uuid of the nsIPrintSettings interface.

Comment 20

[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)

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

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)

Comment 22

[Jan Horak [:jhorak]]

Attachment: Save resolution (dpi) and duplex settings 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.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

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

Comment 24

[Ryan VanderMeulen [: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

Comment 25

[Jan Horak [:jhorak]]

Attachment: 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.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

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

Comment 27

[Ryan VanderMeulen [:RyanVM]]

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