692181 - new TBird 7 printing behavior. No printer-selection dialog offered, with previously used printer

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[gkarasik]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; chromeframe/14.0.835.8; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.21022; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; IPH 1.1.21.4019)

Steps to reproduce:

Click on File/Print in TBird 701


Actual results:

TBird printed directly to my Windows default printer


Expected results:

1) A printer-selection dialog should have appeared; and
2) In TBird 6 I had an alternate printer selected that TBird 701 is ignoring

Comment 1

[Ludovic Hirlimann [:Usul]]

Is this a regression ? Was T5/TB6 working properly ?

Comment 3

[gkarasik]

(In reply to Ludovic Hirlimann [:Usul] from comment #1)
> Is this a regression ? Was T5/TB6 working properly ?

Yes, it is a regression. Previous versions worked correctly.

GaryK

Comment 4

[gkarasik]

TBird 7 is adding the following, set to True, to Config Editor:

print.always_print_silent

Either resetting it or setting to False returns the behavior to displaying the print dialog (although it will continue to ignore the print.print_printer setting in favor of the windows default printer).

Comment 5

[peter]

Regarding the last-used printer not being sticky (i.e. becoming default) (bug 693181):

1.  This is also a regression.
2.  My impression is that print.print_printer has been ignored for many previous versions (possibly because last-selected printer was always remembered -- by a different mechanism), but selecting a printer was nevertheless sticky.

Comment 6

[gkarasik]

(In reply to peter blicher from comment #5)
> Regarding the last-used printer not being sticky (i.e. becoming default)
> (bug 693181):

1.  This is also a regression.
2.  My impression is that
> print.print_printer has been ignored for many previous versions (possibly
> because last-selected printer was always remembered -- by a different
> mechanism), but selecting a printer was nevertheless sticky.

I will test that.

GaryK

Comment 7

[peter]

(In reply to gkarasik from comment #6)
> (In reply to peter blicher from comment #5)
> > Regarding the last-used printer not being sticky (i.e. becoming default)
> > (bug 693181):
> 
> 1.  This is also a regression.
> 2.  My impression is that
> > print.print_printer has been ignored for many previous versions (possibly
> > because last-selected printer was always remembered -- by a different
> > mechanism), but selecting a printer was nevertheless sticky.
> 
> I will test that.
> 
> GaryK

I based that assertion on the fact that when I checked the value of print.print_printer in the course of troubleshooting the current issue, I found that it pointed to a (pdf) printer I had not used for several versions of TB and FF past, not since FF 3 release, and certainly not the printer previous versions of TB had defaulted to in the recent past.

Comment 8

[peter]

I should also probably clarify that the last-used printer is not even remembered during the same thunderbird session.  I.e., the problem occurs with or without a restart of TB.

Comment 9

[peter]

Oops, please disregard my comments 5.2, 7, and 8.  Looking back at old backups, the print.print_printer value in prefs.js was indeed the correct default printer.  My eye must have slipped to the next line which had printer configuration values for an obsolete printer.  Therefore, no need to check on whether print.print_printer was ignored in previous versions.  Sorry for the mixup on my part.

Comment 10

[gkarasik]

I get the same results as you--printer selection is not sticky.

GaryK

Comment 11

[Daniel Holbert [:dholbert]]

I can't reproduce, on Linux, with fresh profile & official Thunderbird 7.0.1
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

I do get a print dialog, and no pages are printed before I've clicked through it.

(However, I do briefly see a small "(Printing)" progress dialog appear, before the actual main Print dialog comes up. Its contents are "(Loading content for printing)"//"Preparing".  That part is a bit odd.  At least in Firefox, that small dialog normally doesn't show up until after you've actually told it to print, I think.)

Comment 12

[Daniel Holbert [:dholbert]]

Gary, does this reproduce in a fresh Thunderbird profile?
(For help in creating an additional profile, see:
http://support.mozillamessaging.com/en-US/kb/using-multiple-profiles )

Comment 13

[peter]

(In reply to Daniel Holbert [:dholbert] from comment #12)
> Gary, does this reproduce in a fresh Thunderbird profile?
> (For help in creating an additional profile, see:
> http://support.mozillamessaging.com/en-US/kb/using-multiple-profiles )

I do not experience Gary's original problem with or without a fresh profile.

However, the problem I am complaining about -- printer choice is not sticky -- occurs both with and without a fresh profile, and no print* entries get written into prefs.js.  (win xp sp3)

Comment 14

[Daniel Holbert [:dholbert]]

Peter: I'm not convinced that what you're describing is a bug -- at least on Ubuntu, all apps appear to preferentially choose the system-default printer.  (Maybe that's not the case on Windows, though.)

Regardless, could you file a separate bug on that issue? Bug pages get unreadable / impossible to track if we discuss multiple issues in one bug.

Comment 15

[Daniel Holbert [:dholbert]]

Oh, sorry -- you filed a separate bug already, and it was marked as a duplicate of this one.

Ludo, are you sure that dupe-marking was appropriate? It sounds like Comment 0 describes something different from bug 693181.

Comment 16

[Daniel Holbert [:dholbert]]

In particular, the lack of [Expected Results part 1] seems to be what this bug was filed on.  Expected Results Part 2 sounds like bug 693181, but in this bug, it's really just a side-effect of Part 1.  (Without a print dialog showing up, of course you can't choose an alternate printer.)

Un-duping -- let's keep the non-sticky-printer-selection over on bug 693181, and leave this bug about the print dialog not showing up at all.  (which so far no one but Gary's been able to reproduce, AFAIK -- Gary, if you get a chance to investigate Comment 12, that'd be much appreciated!)

Comment 17

[gkarasik]

(In reply to Daniel Holbert [:dholbert] from comment #16)
> In particular, the lack of [Expected Results part 1] seems to be what this
> bug was filed on.  Expected Results Part 2 sounds like bug 693181, but in
> this bug, it's really just a side-effect of Part 1.  (Without a print dialog
> showing up, of course you can't choose an alternate printer.)

Un-duping --
> let's keep the non-sticky-printer-selection over on bug 693181, and leave
> this bug about the print dialog not showing up at all.  (which so far no one
> but Gary's been able to reproduce, AFAIK -- Gary, if you get a chance to
> investigate Comment 12, that'd be much appreciated!)

I created a new profile. Print dialog does show up. Print.print_printer setting still ignored. Printer selection still not sticky.

GaryK

Comment 18

[Ludovic Hirlimann [:Usul]]

(In reply to Daniel Holbert [:dholbert] from comment #15)

> Ludo, are you sure that dupe-marking was appropriate? It sounds like Comment
> 0 describes something different from bug 693181.

Yep - sorry.

Comment 19

[Wayne Mery (:wsmwk)]

gkarasik, do you still see this problem?

Comment 20

[Michelle Funches - QA]

This issues has been tagged for regression and or closure.
This was tested with Thunderbird v7, v7.0.1 and 38.7.2 with various physical and PDF printers installed. 
Print dialog successfully displays, can successfully print. Last printer selected is also remembered.
Considering this I will mark this issue as Resolved-WORKSFORME. 
If anyone can still reproduce it, feel free to reopen the issue and provide updated steps/links.

Comment 21

[peter]

This may or may not be the same bug, but...

My observation with versions around 37+ is that the default printer, which used to be set with the pref:

"print.print_printer"

now seems to require the pref:

"print_printer"

Since the latter does not conform to the naming conventions for everything else, I'm guessing it's a typo somewhere in the code where someone accidentally elided "print."

For me, with tb 38.5.1 and 38.7.2 on win 7 sp1 64bit, tb still does not remember the last printer used, and instead reverts to the default printer which I have set in my prefs with "print_printer".

So, at the risk of **** people off, I will reopen this.  I won't be insulted if you close it again.

--peter

Comment 22

[peter]

Apparently, I do not have permission to reopen the bug.

Comment 23

[Michelle Funches - QA]

I checked with bugmaster, we would like to have someone in Thunderbird group review this and make clear what the default behavior should be.

Comment 24

[Wayne Mery (:wsmwk)]

(In reply to peter from comment #22)
> Apparently, I do not have permission to reopen the bug.

Right - you can only reopen your own. But you have bug 693181 :)