Open Bug 916925 Opened 11 years ago Updated 2 years ago

default printer selection inconsistent

Categories

(MailNews Core :: Printing, defect)

x86
Windows XP
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: JimScott, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36

Steps to reproduce:

Current version here is 17.0.8.

1. Reset "print_printer" parameter.
2. Restart TB.
3. Print email (print dialogue should show current system default printer). 
4. Print email again except change printer.
5. Print email again (system default should re-appear, not printer selected in Step 4).
6. Print Preview email and click on print from that screen. The system default printer should appear. Use it.
7. Print Preview email and click on print from that screen. The system default printer should appear. This time select any other printer.
8. Print (NOT Print Preview) email again.
9. Print (NOT Print Preview) email again and change printer.
10. Print (NOT Print Preview) email again.



Actual results:

Assume system default printer is Epson. Alternate printer is Win2PDF.
1. Sets value to blank (or deletes if TB is restarted).
2. as expected
3. Epson appears as default printer. Email prints on Epson.
4. With Win2PDF selected, email prints to Win2PDF.
5. Epson appears as default printer.
6. Epson appears as default and printed.
7. Epson appears as default; changed to Win2PDF and printed.
8. Win2PDF appears as default!!!
9. Win2PDF appears as default; changed to Epson.
10. Win2PDF appears as default.


Expected results:

The theme here is that as long as the print_printer parameter is not set, the system default printer will be used as the TB default.

Once the print_printer parameter has been set, TB will use it as the TB default printer.

The print_printer parameter is ONLY set / changed when the Print Preview print dialogue is used to print an email. The normal print dialogue will have no effect on this parameter.

IMHO, (1) the print_printer parameter should be controlled in a similar manner by all TB print dialogues, and (2) an enable box should be added under Options / Advanced Configuration (right under the Submit Performance Data item) so the User can enable (print_printer parameter controls TB default) or disable (print_printer is ignored and system default printer is always TB default).

Reference to expanded explanation: see Sam Quint's latest post in this thread:

https://getsatisfaction.com/mozilla_messaging/topics/thunderbird_printer_default_selection
Do you also see thie problem in version 24?
Flags: needinfo?(JimScott)
Whiteboard: [closeme 2013-12-01]
Problem? Some might say this is a feature ... being able to lock in a specific printer independently of the system default. Some might like to have a few controls for this "feature". For example, a checkbox to allow locking in a specific printer regardless of the system default; conversely, unchecked, the default system printer would always be selected when the print dialogue box opens. And, a small button to reset the "printer_print" preference at will (allowing the user to delete the current "locked in" printer without having to actually print something).

But I digress. To answer you question, yes. TB 24.1.0 functions exactly as described.

It would appear that Print Preview sets a parameter that Print does not. Obviously this should not happen. My point is rather then just remove the offending line of code, why not turn it into a feature so that folks who want to _always_ have the system default printer appear are happy, and other folks who would like to select a different printer to be the TB default are also happy. The end game of course is to get Print and Print Preview on the same page with regard to the initial printer selection default. Without seeing the actual code, it seems like this would be fairly simple.

Getting these print functions aligned may also solve a host of other problems ... like the folks that are complaining about the paper sizes always changing on them. It's quite possible that the printer selection mixup vis-á-vis Print vs. Print Preview resulted in the paper size they selected being overwritten when the printer changed unexpectedly (or didn't as the case may be). Just sayin... :-)
Flags: needinfo?(JimScott)
Whiteboard: [closeme 2013-12-01]
Jim, sorry to ask again. Do you still see this problem when using the most current version?
Component: Untriaged → Printing
Flags: needinfo?(JimScott)
Product: Thunderbird → MailNews Core
Yes. Version 31.4.0 works exactly as described in Original Description. It is obvious that this inadvertent change in default printers would affect many users who are expecting to see / use the system default printer when a program restarts (as per standard Windows operation). Those operating from scripts will especially be impacted as the "default" printer will be whatever was last selected in Print Preview!
I would not be surprised if more than a few of the printing bugs have their root cause in this problem.
Flags: needinfo?(JimScott)
(In reply to Jim Scott from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/29.0.1547.66 Safari/537.36
> 
> Steps to reproduce:
> 
> Current version here is 17.0.8.
> 
> 1. Reset "print_printer" parameter.
...
> always TB default).
> 
> Reference to expanded explanation: see Sam Quint's latest post in this
> thread:
> 
> https://getsatisfaction.com/mozilla_messaging/topics/thunderbird_printer_default_selection
>

The link at the end of the Description is dead. Apparently getsatisfaction.com no longer hosts the mozilla-messaging topic. Too bad. Another "Yahoo!esque" faux-cost-savings no doubt.
See Also: → 719341
This Bug is still present in TB 38.0.1.

Essentially, 

· using Print does NOT set / change the print_printer parameter.
· using Print Preview DOES set / change the print_printer parameter.
· both the Print AND Print Preview functions WILL use the print_printer parameter IF it is set.

To my way of thinking, the Print and Print Preview functions should work the same vis-á-vis the print_printer parameter. 

NOW, some would like TB, ON STARTUP, to default to the current system printer (which is the normal mode for most Windows-based software). And, some would like TB, on startup, to use the last printer they had selected.

I would suggest that,

(1) Mozilla get both Print and Print Preview on the same page with respect to how print_printer is set / changed, 

and ALSO,

(2) add a user-selectable check box on Tools | Options | General which allows the user to select either "Windows-style printer selection on startup." _OR_ "Always use last selected printer".

This solves the problem of printer selection inconsistency AND allows users to use the method they prefer.

This seems very simple on the surface so I am curious as to why it has not been done.
Also present in win 7 64 bit, tb 38.5.1
IMHO, many printer interface bug reports could be traced back to this aberrant printer selection process ... but without linkage those bug reports just go in circles because of "sometimes it works, sometimes it doesn't" syndrome (ie, the other printing bug cannot be confirmed because of how different people use Print vs. Print Preview); some will change the printer in Print Preview and some will not, which changes the underlying printer selection process.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.