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

(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?

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

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.

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

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

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

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!

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

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.

Nice to have, not a blocker.

(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?

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

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

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