397622 - When select-and-printing multiple email messages, printer setting/properties/configuration only applies to first message.

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Taisuke Yamada]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 2.0.0.6 (20070728)

When printing multiple messages in select-and-print action, only first message follows specified printing configuration.

For example, when I configure printing to be done in 2-up manner, only first one is printed in 2-up form. Others are simply printed with default printer configuration.

Reproducible: Always

Steps to Reproduce:
1.Select multiple messages (use CTRL+LeftClick, or any method you prefer)
2.Select "Print" (from context menu or any method you prefer)
3.Printer configuration dialog will appear
4.Configure to use 2-up paging (anything will do, but this is easy to notice)
5.Printer will print out selected messages...
6....and you will notice only first message is printed 2-up

Actual Results:  
Only first message followed user-specified printer configuration.
Other messages were printed with default printer configuration.

Expected Results:  
Since I selected multiple messages as "print" target, I expected all messages to be printed with specified printer configuration.


Thunderbird should have saved specified printer configuration and use it to print all messages.

This might be a Windows limitation, but nevertheless, I believe this UI behavior is worth marking it as a "bug". I'm not yet sure of a workaround to print 100 messages in 2-up paging.

Comment 1

[Wayne Mery (:wsmwk)]

(I suspect there is one) can you find the product=core component=printing bug and make this bug dependent on it?

Comment 2

[[:Aureliano Buendía]]

With fast search, I can't find any related bug to this (there are many others but are referred to "blank pages" after the first).

I try with deep search on my return.

Comment 3

[gero]

Even worse: When selecting multiple e-mails to print and then canceling the print dialog the cancel only affects the first e-mail--all others are sent to the printer!

Imagine you've inadvertently selected 50 e-mails instead of 5 and now there's no way to stop Thunderbird from printing them. This one is pretty bad.

I just bit me in Thunderbird 2.0.0.22 on Linux.

Comment 4

[[:Aureliano Buendía]]

gero your issue is different from this: please search if you find a dupe in bugzilla. Otherwise fill a new bug

Comment 5

[gero]

Aureliano, I thought this may be the same problem: Decisions in the print dialog (be it parameters or cancellation) are considered only for the first e-mail but ignored for all others. Is there an internal reason that makes these problems different? If that's the case I'll happily file a new bug.

Comment 6

[Wayne Mery (:wsmwk)]

very likely such bugs are related.  but

if you want to search use https://bugzilla.mozilla.org/query.cgi?format=advanced

examples:
- https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&component=Printing%3A+Output&component=Printing%3A+Setup&long_desc_type=anywordssubstr&long_desc=thunderbird+mail+messages&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=---&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
- https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=print&product=MailNews+Core&product=Thunderbird&long_desc_type=anywordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=---&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=short_desc&type0-0-0=nowordssubstr&value0-0-0=address+book

Comment 7

[Berend De Schouwer]

I've got this on Linux with multiple printers.

When printing multiple e-mails, I can choose which printer to send the mails to, but only the first e-mail is printed on the designated printer.  All subsequent mails are printed to the default printer.  That's horribly annoying in an office with multiple printers.

Comment 8

[Wayne Mery (:wsmwk)]

Berend, I can't reproduce your issue in win7 using current trunk. However, more relevant is the fact that you are seeing a different problem - this bug is not about the wrong printer being used.

Comment 9

[gero]

I can reproduce Berend's issue with Thunderbird 3.1.10 on Linux.

As to whether this issue belongs to this bug please refer to my comment #5. IMHO Berend's issue matches the OP's description perfectly.

I'm a bit worried that 3 1/2 years after being reported this bug hasn't even been assigned to anyone. Can anyone help?

Comment 10

[Wayne Mery (:wsmwk)]

the reporter's issue is a duplicate of Bug 192496 - when printing multiple mails, some print settings apply only to the first one - but for now I'm going to set dependency to facilitate searchability


the cancel issue is a duplicate of bug 87474 - Only first print job is prompted for print or cancel

Comment 11

[gero]

Thanks Wayne, you're obviously right.

The scary part: These bugs are 7 and 10 years old, respectively--and still not assigned to anyone.

Comment 12

[Tristan Miller]

Confirming bug still exists with Thunderbird 17.0.3 (GNU/Linux, x86-64).

This is somewhat of a security problem—today I selected multiple confidential messages and instructed Thunderbird to "print" them to a local PDF file.  Instead all but one were sent to a networked printer in another room where they were retrieved by someone who shouldn't have had access to them.