Closed
Bug 268415
Opened 20 years ago
Closed 20 years ago
Print Behavior Changed
Categories
(Thunderbird :: General, defect)
Thunderbird
General
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird1.0
People
(Reporter: mwestfall, Assigned: mscott)
References
(Depends on 1 open bug)
Details
(Keywords: fixed-aviary1.0)
Attachments
(1 file)
642 bytes,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 Build Identifier: TBird 0.9 Much to my dismay I have noticed that when printing multiple messages you are "provided" (I prefer the word annoyed) by a print dialog for EACH Message. I just rejected 20 manuscripts, and had to sit here and wait and hit OK for EACH Print dialog, instead of just selecting the 20 e-mails and hitting OK Once, and then going to do something else. I see no logical reason you would want to be "provided" (annoyed) by a print dialog for EACH e-mail if you select more than 1 e-mail and hit print. Obviously if you are selecting more than 1 e-mail... you want to print them all. Why in the world would you want to print say 19 of them on 1 printer and 1 of them on another printer? Ohh you wouldn't... and if you DID want to do that... you would select the first 19. Print... Select Printer 1... hit OK --one time--. Then you would select the 20th e-mail.. and print it. Please excuse my sarcasim, but there is no reason this print behavior should have changed. If you are determined to "provide" this "functionality" please create an option in page setup or in options to turn it off, for those of us in the normal world who select 20 e-mails and print them all to the same printer. Thanks Reproducible: Always Steps to Reproduce: 1. 2. 3.
Comment 1•20 years ago
|
||
(In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 > Build Identifier: TBird 0.9 > > Much to my dismay I have noticed that when printing multiple messages you are > "provided" (I prefer the word annoyed) by a print dialog for EACH Message. > > I just rejected 20 manuscripts, and had to sit here and wait and hit OK for EACH > Print dialog, instead of just selecting the 20 e-mails and hitting OK Once, and > then going to do something else. > > I see no logical reason you would want to be "provided" (annoyed) by a print > dialog for EACH e-mail if you select more than 1 e-mail and hit print. > > Obviously if you are selecting more than 1 e-mail... you want to print them all. > Why in the world would you want to print say 19 of them on 1 printer and 1 of > them on another printer? > > Ohh you wouldn't... and if you DID want to do that... you would select the first > 19. Print... Select Printer 1... hit OK --one time--. Then you would select > the 20th e-mail.. and print it. > > Please excuse my sarcasim, but there is no reason this print behavior should > have changed. > > If you are determined to "provide" this "functionality" please create an option > in page setup or in options to turn it off, for those of us in the normal world > who select 20 e-mails and print them all to the same printer. > > Thanks > > Reproducible: Always > Steps to Reproduce: > 1. > 2. > 3. HAving the same problem when upgrading to .9. I need to print out some 600 emails at one time, making this a now impossible task with the change in this version.
Assignee | ||
Comment 2•20 years ago
|
||
people talked me into going with the other behavior in .9
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Thunderbird1.0
Assignee | ||
Comment 3•20 years ago
|
||
Reporter | ||
Comment 4•20 years ago
|
||
Okay I read the previous bug you referenced in your last note.... the problem as described in the other bug states... that if you hit print when you have more than 1 message selected, and you hit cancel... it does not cancell the other messages you have highlighted.... this was fixed by asking you to print EVERY message.... the plague of open source development.... The cancell should cancell all the print jobs.... removing the subsequent silent print calls is not the appropriate way to fix the problem. Yes it solves the one problem, but it generates another one..... where, if you ACTUALLLY want to print more than 1 message at a time.... This other person, should Edit their toolbar... and make the Print and Delete buttons not so close together.... better yet... hit Delete on your keyboard.... problem solved..... removing the silent print call, which is there for a reason, is not the soloution to this problem.... Thanks for backing it out scott.... Other guy.... edit your toolbar and use the delete key on your keyboard..... Crossposting this with other bug.....
Like I said in bug 87474 comment #14, I understand the purpose of that call. However, it's not working as intended. When you hit cancel, it's not cancelling *all* of the remaining print jobs. Again, as I explained in bug 87474, I would prefer being prompted for each print job rather than having the silent print behavior. It is the lesser of two evils IMO. The end-user should not have to "edit their toolbar" to prevent the application from doing something foolish. I triggered the bug by accident the first time but I've run into it a number of times since then. I go to select 5 messages to print, and notice that a 6th one got slipped in by accident. Hit cancel when the first prompt comes up and the 5 remaining messages (including the wrong one) get printed anyway. That's not even close to the desired behavior and if I need to cancel each individual message to avoid it, so be it. Matt, since you obviously know better than "the other guy", please step up and provide the proper fix rather than just reverting to the incorrect behavior. Make it a pref or whatever but thunderbird should not be shipping with this bug, hence the pressure that Scott received (not from me) to fix it.
Assignee | ||
Updated•20 years ago
|
Keywords: fixed-aviary1.0
Reporter | ||
Comment 7•20 years ago
|
||
""to prevent the application from doing something foolish."" The application only does what it's programmed to do, if you hit the wrong button, you can't blame the application for that.... I, as do most people, don't hit Print instead of Delete on accident, therefore the lesser of two evils for everyone but you, is to not have to hit OKAY 20 times if I want to print 20 e-mails. Likewise, I'm sure you would agree that if you hit print incorectly instead of delete, you don't want to hit Cancell 20 times... Furthermore, Thunderbird is a testbed.... as such, if you want to make sure people poke at things enough before they get on your computer, use Mozilla... If I knew enough about C or C++ whatever thunderbird is coded in... I would of course fix it... hell I could probably figure it out on my own anyway if I wanted... I mean... think about it.... All you have to do is modify it so that if you hit cancell, it just exits the loop, instead of continuing the loop and doing a silent print call X - 1 number of times. But yes, not cancelling ALL the messages when you hit cancell is a pretty big flaw.... but requiring someone to hit OKAY or Cancell on EVERY message is not the way to fix it at all.
Assignee | ||
Comment 8•20 years ago
|
||
I think this is issue is worse than the cure. I'll re-open the original bug in the hopes that someone can come up with a better fix. fixed branch and trunk.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 9•20 years ago
|
||
The only thing I would like to add is that maybe it could ask "You have just chosen to print 600 messages. Are you sure?" with a "PROCEED" or "NO" choice. Just a thought.
Reporter | ||
Comment 10•20 years ago
|
||
That would be one way to address the issue, is have an "out" before the "print loop" even starts.... so we have 2 options 1) When you hit Cancell on first print dialog, it exits the print loop and doesn't call the subsequent silent print calls. 2) Ask before even entering the print loop if you want to print more than 1 message. I think Option 2 is best myself, as it doesn't cause an extra click for anyone.
You need to log in
before you can comment on or make changes to this bug.
Description
•