326093 - Actually using print.print_printer preference in print dialog

Status: RESOLVED WORKSFORME

(Toolkit :: Printing, enhancement)

Description

[Arne John Glenstrup]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060119 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060206 Firefox/1.6a1

The recently selected printer as saved in the print.print_printer
preference is not used (despite the fix of bug 312583, bug 323781 and bug 324072),
because the print dialog itself decides to use the first printer on the 
list as the default printer.

Reproducible: Always

Steps to Reproduce:
1. Open print dialog
2. Print to some printer not at the top of the list
3. Open print dialog again

Actual Results:  
The top printer is still the selected default

Expected Results:  
The last used printer should be the selected default printer.
(Alternatively, one should be able to set a preference indicating
whether one always wants to use the system default printer, or the
last used printer.)

(I'm leaving this as a "minor" severity bug, although it can be annoying
repeatedly to have to select a non-system-default printer.)

Comment 1

[Arne John Glenstrup]

Attachment: Patch attempting to fix bug by reading print.print_printer pref in printdialog.js

Comment 2

[Ian Neal]

(In reply to comment #1)
> Created an attachment (id=210875) [edit]
> Patch attempting to fix bug by reading print.print_printer pref in
> printdialog.js
> 

What happens if that printer no longer exists?

Comment 3

[Arne John Glenstrup]

(In reply to comment #2)
> (In reply to comment #1)
> > Created an attachment (id=210875) [edit]
> > Patch attempting to fix bug by reading print.print_printer pref in
> > printdialog.js
> 
> What happens if that printer no longer exists?

The intention with the patch code is to only select a default printer that
appears in the list of printers passed to appendPrinterNames().
If any of these printers no longer exist, I believe that problem should be
fixed elsewhere.

Comment 4

[Ian Neal]

Okay, having a less-sleepy look at this.

The problem I see with this is that, if you are roaming user (either via roaming profile or using some sort of thin client environment), you will end up with the last printer you printed to rather than the default printer for the computer you are currently using. So if you roam between offices then you may end up printing to a printer in another part of the country/world. Saying that this will only happen if you have both printers setup on the computer you are using which is probably a fairly unique set of circumstances.

Comment 5

[Arne John Glenstrup]

(In reply to comment #4)

I don't see why this should be a fairly unique set of circumstances;
wouldn't it be a rather common laptop setup?

In any case, however, I think it is more natural for a roaming user
to think actively about which printer to print to, than for a stationary
user to remember EACH time to select the right printer if it is not the
system default.  Furthermore, the roaming user need only select the
correct printer once every time she moves.

Comment 6

[Ian Neal]

(In reply to comment #5)
We have about 400 roaming users and the only time they think about which printer they are going to use is when it doesn't work or they want to print off in colour. They just expect to print to the closest printer to them, which we have set to be the default one for each roaming position.

I think it is okay to use the last used printer within the same session but once you restart the session it should be the default printer.

Comment 7

[Arne John Glenstrup]

(In reply to comment #6)

What an impressive amount of roaming users!

However, I am certain one could find a similar amount of users that would
find the "always print to system default even though you just printed off
to another printer" annoying.

This just goes to show that we should consider things carefully before
committing to any one solution.

> I think it is okay to use the last used printer within the same session but
> once you restart the session it should be the default printer.

This, I suppose, could be achieved by letting the firefox (or thunderbird,
or...) script adjust the print.print_printer setting before invoking the
binary.  However, dynamic context changes while mozilla is running (e.g.,
moving the laptop it is running on) would not be reflected.

Achieving the roaming behaviour by letting the binary force the resetting each
time it is fired up will make it difficult for users that expect the last
used printer to be used next time (if for instance mozilla was closed down
briefly to reset cookies, by accident, crash or similar).  This would require
changing the system default just before invoking mozilla, affecting all other
applications on the box as well.

Perhaps the best solution is to have a preference, print.print_default_printer_is_system_default.  This respects dynamic context
changes, and also makes it more explicit to users/sysadms what is going on
inside.

Alternatively one could check a MOZ_PRINTER environment variable: If it is
set, use this printer, else use last used printer.  Dynamic context 
changes would, however, still not be reflected.

Comment 8

[Ian Neal]

We should probably do what other applications do (or the majority) if it is fairly easy to do. The minimum we should do (if we don't already) is make sure the listed printer in the printer dialog box is the one that will get printed to when OK is clicked. I do not think that is being done consistently, just tried from SM and in browser it lists the last used whereas in mailnews it lists the default!

Comment 9

[Arne John Glenstrup]

(In reply to comment #8)

> The minimum we should do (if we don't already) is make sure
> the listed printer in the printer dialog box is the one that will get printed
> to when OK is clicked. I do not think that is being done consistently, just
> tried from SM and in browser it lists the last used whereas in mailnews it
> lists the default!

Oh, disaster!  That's sure to scare users away.

How do we go about rectifying this?  I was under the impression that there
was one common print dialog used by all modules.

Just checked GIMP; on my installation it seems to save the last used printer
between sessions.

Comment 10

[rashkae]

I'm using this patch now, thanks it works great.  It might be minor, but this bug was irritating me greatly.  (Note: I like Mozilla to default to the Postscript Driver which I've configured to print through kprinter, but Firefox 1.5 was always defaulting to CUPS)

As for the suggestion that Mozilla default to the system default at every session, may I instead suggest we (meaning you) make "System Default" a selection in the print dialogue?  I realize that some per-printer preferences will no longer be saved to individual printers, but that's probably a small price to pay for someone who changes system defaults... In the mentioned case of mobile users, users would probably expect their margin preferences to be the same when they change location (and system printer) anyhow.

Comment 11

[Mike Connor [:mconnor]]

Nice to have, not a blocker.

Comment 12

[Arne John Glenstrup]

(In reply to previous comments)

Ian, what do you think of rashkae's suggestion of providing users with an
explicit choice in the UI for using the system default printer?

I realise that this can get quite involved, but considering your argument
about roaming users, and my argument about repeated printing to a non-
system-default printer, this might be the right thing to do.

If we are to do this, what should it look like?  Well, first I thought of

SUGGESTION 1: A virtual printer, named System/default is added to the list
in the print dialog.  This would probably entail generating it somewhere
in nsDeviceContextSpecG.cpp(GlobalPrinters::InitialiseGlobalPrinters),
and when printing, recognising it as a virtual printer, and then
substitute the actual system default for it.

However, aside for the technical complications implementing it, it has
the HCI drawback of giving the user the visual impression that it is
different from all the other printers on the list, which it is not.

This led me to think of

SUGGESTION 2: Add a check box "Use system default printer" to the print
dialog, and whenever a print job is launched, if this box is checked, 
the system default printer is looked up and used.  Preferably, the list
of printers should be greyed and the current system default printer
selected when the box is checked---although I don't know whether this is
doable in practise.

The added advantage of this approach is also that users can save per-
printer preferences (and actually realise they are doing so!) to the
current system default printer.


Whichever way, we should also consider when to look up the system default
printer.  HCI-wise, it should probably be done at the instance the dialog
is created.  However, might there be situations where this per-printjob
lookup would be too costly in system resources or user response time?

  ------

Ian, what do you think?  Does it sound sensible, usable, feasible?
And if so, what are the next steps?

Comment 13

[Ian Neal]

I'd like to see how things are affected once the patch for bug 324072 has landed

Comment 14

[Arne John Glenstrup]

(In reply to comment #13)

OK, now that bug 324072 has been fixed, let us discuss what to do about
this issue.

How about attempting implementation of suggestion 2 of comment #12?
I realise it changes the user experience, so we should be cautious,
but the change is minor, I think.

Comment 15

[Mike Connor [:mconnor]]

Comment on attachment 210875 [details] [diff] [review]
Patch attempting to fix bug by reading print.print_printer pref in printdialog.js

Really not the right person to review this stuff, probably Neil Rashbrook, though it seems like we really want to get a better plan on what we want to do with this in general...

Comment 16

[Ian Neal]

(In reply to Arne John Glenstrup from comment #14)
> (In reply to comment #13)
> 
> OK, now that bug 324072 has been fixed, let us discuss what to do about
> this issue.
> 
> How about attempting implementation of suggestion 2 of comment #12?
> I realise it changes the user experience, so we should be cautious,
> but the change is minor, I think.

I've not a problem with that but as suggested in comment 15, someone line Neil Rashbrook or other people that have reviewed patches to printdialog (like vladimir or pavlov if they are still around) would need to confirm that is an enhancement they want.

Comment 17

[Jonathan Watt [:jwatt]]

WFM on Fedora 36.