Open Bug 66806 Opened 24 years ago Updated 3 years ago

Print selection is always disabled for MailNews messages (only composition has correct behaviour)

Categories

(MailNews Core :: Printing, defect)

defect
Not set
major

Tracking

(Not tracked)

REOPENED

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 2 open bugs, )

Details

(4 keywords, Whiteboard: [gs] [current STR & behaviour in comment 107] [ugly workaround checked in - selection is force-printed, if there is a non-composition selection])

Attachments

(1 file, 1 obsolete file)

Build ID: new trunk (tip--after Rod's checkin)

You can't print selected text in the mail message pane...
Can you expand on this.  Did it used to work.. are you talking about frames, 
Thanks.
It didn't used to work, because selection printing never worked before Rod's 
checkin...

To reproduce, open MailNews, select a message in the threadpane, select text in 
the message preview pane (at the bottom), and File > Print.  The `Selection' 
radiobutton is disabled.
I think this is MailNew problem to enable a radio button.. and then set the 
print selected text.  I will assign to Mail News and then they can contact 
either Myself or Rod Spears on what they need to do to support this.
Assignee: dcone → sspitzer
Component: Printing → Mail Window Front End
I tried to print text and got the message with a huge blank area down the middle
of the page...

Printed without selected text just fine (same message).
sorry the above should be 66806

http://bugzilla.mozilla.org/show_bug.cgi?id=66806

Opened: 2001-01-27
Confirming bug on OS/2 and Linux build.
Hardware/OS -> All/All
Component -> Printing
Clarifying Summary.
Severity: normal → major
Component: Mail Window Front End → Printing
OS: Windows ME → All
Hardware: PC → All
Summary: Can't print selected text in message pane → Print selection is always disabled for MailNews messages
*** Bug 137633 has been marked as a duplicate of this bug. ***
*** Bug 192101 has been marked as a duplicate of this bug. ***
*** Bug 207397 has been marked as a duplicate of this bug. ***
*** Bug 214234 has been marked as a duplicate of this bug. ***
Hi,

Anyone has any idea on the status of this?  It's v. frustrating to NOT be able 
to print just a certain portion of the mail.  Many times the mail goes back and 
forth between clients and as a result, all the previous mail is printed and we 
can't find away around that because the print selection is grayed out.

I have a few users that I have recently migrated from Outlook Express, which are
very happy with mozilla mail, except for the lack of "Printing selected text in
emails".

Could someone at the most fix this, or at the least give us a status report? :)

Thanks!
*** Bug 242007 has been marked as a duplicate of this bug. ***
Is this on anyone's radar or is there some underlying issue that makes it a
difficult fix so it's low on the priority list?

thx
*** Bug 242641 has been marked as a duplicate of this bug. ***
*** Bug 262439 has been marked as a duplicate of this bug. ***
Is anyone working on this problem?
Product: MailNews → Core
*** Bug 267490 has been marked as a duplicate of this bug. ***
*** Bug 259731 has been marked as a duplicate of this bug. ***
Expecting a '-' due to the age of this bug, but trying anyway - see comment #11
for why this is important.

As a side note, I can print selection from a displayed RSS feed in Thunderbird,
so the code is obviously there... 
Flags: blocking-aviary1.1?
is anyone willing to take care of it? 
I have people migrated from Outlook Express too, and they NEED (for a matter of
header) this function... they'll it! 
I'm not able to code or I'll do by myself... 

thank you guys, 

Miles 
Assignee: sspitzer → nobody
Flags: blocking-aviary1.1? → blocking-aviary1.1-
QA Contact: esther
(In reply to comment #20)
> As a side note, I can print selection from a displayed RSS feed in Thunderbird,
> so the code is obviously there... 

With TB, version 1.0.6 (20050716), linux build it's not even possible to print a
selection from a displayed RSS-feed. I just wanted to add that. 
It's still not working on TB 1.0.6 under Win2K
It should be possible to print the Message Part without the Headers.  This
problem is a distraction from the real issue but is a workaround.
A work-around I found is to hit the Forward button and then print
the selection from that window.  Or if that doesn't work, try
Forward as inline, or Reply, or View > Message Source.  Printing
the selection works from all of those windows.
(In reply to comment #25)
> A work-around I found is to hit the Forward button and then print
> the selection from that window.  Or if that doesn't work, try
> Forward as inline, or Reply, or View > Message Source.  Printing
> the selection works from all of those windows.

  huh, nice find.  still something that needs to be fixed though.
please anyone empowered should assign this bug to printing@core.bugs and add the useless-UI keyword
it looks like it lost attention in the pile of bugs. ;)
Assignee: nobody → printing
Keywords: useless-UI
I too just migrated from Outlook Express and find the lack of being able to select text from a message for printing an annoyance.
This is a major pain.
Can we get an ETA for the fix?
changing to suite until proven otherwise, see Bug 326539 comment 3
(besides, bugs in the print component are just lost)
Component: MailNews: Printing → MailNews: Main Mail Window
Flags: blocking-aviary1.5-
Product: Core → Mozilla Application Suite
(In reply to comment #25)
> A work-around I found is to hit the Forward button and then print
> the selection from that window.  Or if that doesn't work, try
> Forward as inline, or Reply, or View > Message Source.  Printing
> the selection works from all of those windows.

Edit as New also works.   (TB 1.0.x thru 1.5.0.2)
(In reply to comment #30)
> changing to suite until proven otherwise, see Bug 326539 comment 3
> (besides, bugs in the print component are just lost)

If this means the bug is thought to apply only to the full Suite, that is not the case.  It has been in Thunderbird and its predecessors for as far back as I can remember.  I see the bug you referred to is TB-only.  Should both be combined into one 'core' bug?

.. and then fixed!

(In reply to comment #32)
> Should both be combined into one 'core' bug?

No, if you read the developer's comment in Bug 326539 comment 3 the current best guess is two different fixes may be required.


(In reply to comment #29)
> This is a major pain.
> Can we get an ETA for the fix?

No ETA.  There are no ETAs in this world even if someone drafts a patch. Otherwise your guess is as good as anyone's.
Assignee: printing → mail
I can also reproduce this with Thunderbird 1.5.0.5. Is there any plan to fix this? I don't think it's that difficult if it's already implemented in other parts of Thunderbird.

I also have one user migrated from Outlook Express and he's missing that functionality.

I'm hoping that gets fixed soon...
I have this version :
version 1.5.0.7 (20060915)
It does not seem to be fixed...
Does anybody work on it ?
This has been a bug for five years, surely someone knows the codes to fix it.
I have this version :
version 1.5.0.8 (20061025)
It does not seem to be fixed...
Does anybody work on it ?
This bug has languished for one and a half months shy of SIX YEARS.  Would someone please kindly tell me why on earth any bug that has this much of an impact on usability is allowed to persist even for six MONTHS let alone six years?

There have been numerous explanations for why this is important, but I'll add yet another to the list - trying to print out an airline itinerary with only the important stuff and not the useless info **** at the top should not require an edit as new before I can print only a selection.
Amen to all of the above.  Somebody must know how to allow "Print Selection".  Ink and paper cost money.
I'm sure someone does, but that doesn't mean that he has the time or inclination to fix it.  Remember, many (if not most) Mozilla developers aren't paid to work on Mozilla, so they'll fix whatever bugs they want, when they want.  
@Timur Tabi: That's right but the bug has its seventh birthday tomorrow. And i don't think that this is a great bug. So when someone fixed it, pleaaassee put it in TB.
You'll notice that Firefox doesn't have "print selection" either, as far as I know. Since Thunderbird uses the same core html code and core printing code as Firefox and Seamonkey, this is really a core issue, somewhat outside TB's control.
I think until bug 124096 is "fixed", there will always be thousands of bugs just like this one.
Maybe the upcoming "marriage" with Eudora will resolve some issues.
It does for me in FF2.0.0.3 and previous. The option is not on a menu but, if text on the page is selected', appears as an enabled radio button 'selection' under 'print range' in the print dialogue shown after 'Print' is clicked.

In TB1.5.0.10, the print dialogue is also shown and that radio button is still present but is always disabled(greyed out).

Does that mean that the problem is with mail/news and *not* in the core?
Above (Comment 45) was in reply to

David Bienvenu comment 42

"You'll notice that Firefox doesn't have "print selection" either, as far as I
know. Since Thunderbird uses the same core html code and core printing code as
Firefox and Seamonkey, this is really a core issue, somewhat outside TB's
control".

but that was not obvious since '[reply]' apparently does not quote the relevant post as it should.
Firefox 2.0 has (In reply to comment #46)
> Above (Comment 45) was in reply to
> 
> David Bienvenu comment 42
> 
> "You'll notice that Firefox doesn't have "print selection" either, 

At least FF 2.0.x does have it. BTW: TB 2.x does not. 

Oh, well, it's hard to believe that this bug has not been fixed in six years. Open Source does not always work as advertised, unfortunately.
I doubt you have seen this open source project advertise it's printing capabilities - if the volunteer(s) step forward then it happens.

anyways, see my comment in bug 291609
which part of the code has the problem. its better to print 1 page instead of 83 pages. 
(In reply to comment #48)
> I doubt you have seen this open source project advertise it's printing
> capabilities - if the volunteer(s) step forward then it happens.

That's not what I meant. What I wanted to say is that in this case the open source development model hasn't worked (yet). It has often been said that open source is better because bug get fixed quicker. Now, this bug is quite a visible one. In fact, it is made it gave me a hard time convincing some colleagues to migrate to Thunderbird. It is quite annoying to see 10 pages come out of the printer when you want to print out just 10 lines. 

Now, I would have assumed, that this is so annoying that at some point, someone with the necessary skills (which I, unfortunately don't have) would come forth and fix it, given that, according to what was said above, fixing this cannot be too complicated. 
We're getting off-topic now, but I feel compelled to address Johannes' complaint.  The problem, Johannes, is that there are THOUSANDS of bugs just like this one, and there just aren't enough programmers available to fix them all.  So you might be complaining about this bug, but there are hundreds of people just like you complaining about other bugs.  A given developer can only do so much in a day.

Maybe you should go to rentacoder.com and hire someone to fix this bug?  How much is this bug worth to you?
People who've voted for this should probably also vote for the one Wayne links to, which is specifically for Thunderbird (as opposed to Mozilla Suite):

https://bugzilla.mozilla.org/show_bug.cgi?id=291609
Add me to those that are very disappointed that Thunderbird does not allow print selection only. This is a feature that I use very frequently in email and makes Thunderbird unusable for me. Otherwise, looks like a great program. Hopefully the Penelope project will take care of this issue.
Please Take Care about it!

I change 20 terminal from Outlook to Thunderbird.

Don´t help Gate´s blanks brains a good reason to not change to

Great Imap Works!
Is it almost 8 years now?  This bugs me sufficiently that I would definitely put some money where my text is if the donation option (post 53) worked - and I almost never feel a need to do that.

Joe 
This is a rather annoying one for me too.  It would be so much nicer (and such a saver of trees) for this feature to work.

Currently my only workaround is to print to a PDF file and then crop out the text that I didn't want and print what is left.
(In reply to comment #42)
> You'll notice that Firefox doesn't have "print selection" either, as far as I
> know.

It's there at least now for ff3, as long as you have a selection in the document. (Tested on linux.)

Somewhere, somehow we want kRangeSelection to get set.
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Printing
Product: Mozilla Application Suite → Core
QA Contact: printing
FF 2.0.0.12 with windows XP has print selection
Print Selection is available in Firefox 2 with Mac OSX, too, but you may have to hunt for it in your printer settings.
The original problem isn't actually talking about Firefox, the problem is with Thunderbird.
From Mozillazine forums

[quote="klades"]In the meantime the bug will be fixed, I think to have found a method to print just selection to insert in my extension PrintingTools.
So, try the next version (0.2.2), I'll release it soon and give me some feedbacks.
Ciao, Paolo[/quote]

I have installed this and it works for me under kubuntu Linux.
If a selection exists, just the selection gets printed if this feature is configured.  It can be toggled on and off in the extension's preferences.

Oops.  The extension mentioned in post #61 is availabe at:

http://www.nic-nac-project.org/~kaosmos/index-en.html
Thanks. Works fine with Windows XP and TB 2.0.0.12. Again: It's just so embarrassing that we've to use an extension for this...
Tried Printing Tools 0.2.2.1 extension today with TB 2.0.0.12 on Vista Business. Even with all other extensions disabled, I do not get the "Print Selection" radio button when there is text selected. I do get the radio button when in the Forward or Edit As New windows. 

I very much appreciate the effort placed into the extension, but would much rather see the core code fixed. The code MUST be there, as it workd in the edit as new and forward windows. 

This bug almost makes me want to go back to school to learn the coding necessary to fix this ancient bug...
It doesn't show it, but it works! Did you try it? No? Why complaining then? Stupid...
We're here to help each other.  Everybody gets frustrated when things don't go as desired.  The extension doesn't claim to alter the gui, just the behavior.  I'm sure messing with the gui would be a lot more code and expertise and time - to say nothing of getting the code approved and merged into the development tree.  If you check the print selection option in the preferences for Print Tools, then whenever you print something with a selection made in it, just the selection prints.  No questions asked.  It's not as wonderful as a radio button that works, but it really is a major contribution to usability.
I'm voting on this, as I'm experiencing the same problem.  I can't believe this still isn't fixed; an extension shouldn't be needed.  This is basic printing functionality, *every* program out there does this...and it's a seven year old bug?!?
Flags: blocking-thunderbird3?
Product: Core → MailNews Core
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Priority: -- → P4
Retriaging according to new policy for flags.
https://wiki.mozilla.org/Thunderbird:Release_Driving
(bugs marked wanted- don't indicate we wouldn't accept patches, but that they're not going to be the focus for release drivers)
Flags: wanted-thunderbird3+ → wanted-thunderbird3-
Shouldn't this bug be blocking Thunderbird3? I found it hard to believe that this bug been around for such a long time. This is just basic functionality. 

Firefox 'print selection' function works perfectly fine but Thunderbird isn't. And by the look of it, the dev doesn't think that this bug is worthy enough to make it to Thunderbird 3!
Nobody said that, only that there are also other bugs that are more worthy. We have limited man power, so patches are very welcome!
In Comment #52 in this bug and Bug 291609 Comment #6, this bug is for the Mozilla (SeaMonkey) Suite, whereas 291609 is for Thunderbird, and that in the past was justified to prevent Bug 291609 from being marked a duplicate of this bug.

However, bug 291609 was recently marked a duplicate of this bug, and verified as a duplicate. The action and the comments contradict each other, and I am confused as to which is correct.

Can someone familiar with these distinctions please confirm that the above-referenced comments are incorrect, and that it is sufficient for Thunderbird that this bug is listed for "Product: MailNews Core"? (Naturally, if this was an oversight and the distinction is important, Bug 291609 should be re-opened)

Thanks.
It's ok, that bug 291609 was marked as duplicate of this bug. The product "MailNews Core" handles issues for both products, means Thunderbird and SeaMonkey are both affected by this due to a core issue.
Hej,

I investigated this bug a bit in the latest shredder code base and want to share my knowledge to give some insight on the real issue of this bug.

From the users perspective it looks like the developers just have to enable a radio button and then printing a selection will work out-of-the-box. However it is not that easy ;)

In opposite to Firefox, where printing a selection works fine, Thunderbird uses a slightly different code base and approach to print a document. Under Firefox, the document that the user can see in his browser is the same that is used by the printing engine to put it on the paper, so every selection the user has done in the browser window is known to the printing engine as they share the same document.
In Thunderbird the message pane view uses a different document than the printing engine, because in the message pane view, the mail headers (subject, from, to, etc.) are separated from the mail content, whereas the printing engine uses a document where headers and content are combined. That implies two things:
  1) The structure of both documents differs because there are rendered/layouted separately
  2) The selection that is done by the user in the message pane view isn't available in the document that is used by the printing engine

The latter is the reason why the radio button is disabled, by the way...
Transferring the selection from one document to the other is however a difficult and error prone task (and sometimes impossible)...

So if you rethink that, the printing engine (and the printing dialog) has no chance to offer to print only the selection, as long as Thunderbird uses two separated documents.

Now you might object to that statement, because the PrintingTools extension from comment #61 can print a selection, however it follows another approach:
The user can't select whether he wants to print only the selection or the full document when the printing dialog is open, but he has to select that a priori
in the PrintinTool configuration dialog. That is because the PrintingTools extension just overwrites the content of the document, that is used by the printing engine, with the users' selection from the message pane view document
before the printing engine and printing dialog is activated.

So one approach to fix this bug would be to remove/hide the 'Print Selection Only' button in the printing dialog for Thunderbird and have the following defined behavior:
  If the user has selected some text in the message pane view, only this selection will be printed, otherwise the complete document.

I currently try to come up with a patch for this behavior, now you, the users, have to decide whether that is an acceptable solution.

Ciao,
Tobias
Hej again,

just for clarification, the two separated documents are only used when printing from the main window with an active message pane view. If you print from the window that opens when choosing Message -> 'Forward As' -> ... then the same document is shared between this window and the printing engine and therefor the 'Print Selection Only' button is enabled.

Ciao,
Tobias
The attached patch uses the same technique like the PrintingTool extension.
It replaces the content of the document that is used for printing with the content of the selection the user did.
The patch doesn't hide the 'Print Selection Only' button (technically not possible), however that is only a minor cosmetic issue IMHO.
Attachment #402069 - Flags: review?(bienvenu)
Attachment #402069 - Flags: ui-review?
Comment on attachment 402069 [details] [diff] [review]
Patch that allows to print only selection if user has selected some text

asking for ui review, since this is really a UI question.
Bryan, what this patch does is:

If there is a selection in the message pane, just print that, otherwise, print the whole message.

The print dialog still shows a disabled print range "selection" radio item.

I don't have a feel for the possibility of surprise at this behavior is worth having the ability to print just the selection. I believe for the reply quoting using the selection we tried to set some sort of minimum selection length before just quoting the selected text. I think at a minimum, we'd want to do the same here.

Tobias, thx very much for the patch; sorry it took me so long to get to it.
The new version of the patch only prints the selection if at least two words have been selected (that's how the reply quoted selection does it as well).
Attachment #402069 - Attachment is obsolete: true
Attachment #410471 - Flags: review?(bienvenu)
Attachment #402069 - Flags: ui-review?
Attachment #402069 - Flags: review?(bienvenu)
Attachment #410471 - Flags: review?(bienvenu) → review+
Comment on attachment 410471 [details] [diff] [review]
Patch that allows to print only selection if user has selected some text - checked in.

can you use let instead of var for the local vars? And, since you only care if there are more than one word, you can pass in the limit to split, e.g.,

+  let words = selection.toString().split(" ", 2);

r=me, with that change, thx for the patch.
Attachment #410471 - Flags: ui-review?(clarkbw)
I also noticed that if I double click on a word, your code still prints just the selected word, I think because "split" somehow generates an array of two elements. Double clicking a word includes the trailing space in the selection. If I swipe select just a single word with no spaces, split does the right thing. I'm not sure if we care or not. Anyway, I've asked for a ui review from clarkbw just to make sure he's ok with print always printing just the selection, if there is more than a single word selected.
I can't seem to get this working on the mac
Tobias

Thank you very much for your clear explanation in Comment #75 and Comment #76. I know understand what the problem is and why it is difficult to make Print Selection work.

I am a dedicated user of the PrintingTools extension. PrintingTools has some nice user selectable options that also allow the user to “tune” the tool to print exactly what one wants to print. There is however one problem. If the user has selected some text for any reason (for example to cut and paste into another document) and forgets, or does not know, to un-select the text, the selected text is what will print. The print selection radio button is still disabled. I consider myself a reasonably expert user yet I have several times printed a selection only (under PrintingTools) when I actually wanted to print the whole document.

This same problem applies to the patch. One must not forget that there are many non-expert users out there that will find this behaviour confusing. If it is not possible to enable the Print Selection radio button I am not sure that this “work around” should enter the release code. 

This behaviour is similar to that of selected text being the only original text that appears in a Reply email. I must say I like this feature (unrelated to the current thread) and would not want to loose it despite the occasional confusion.

I can see that a lot of changes would need to be made and lot of code written in order to change the way in which the print version of the document is generated but I find it hard to believe that it is not possible at all. I have no idea how other email clients achieve this but certainly MS Outlook can do it. 

Is it not possible to generate (or re-generate) the print version of the document at the time the Print button is clicked? (Perhaps only in the case that a selection has been made) In this way if there is a selection it could be marked as selected in the print version and then the Print Selection radio button in the Print Dialog could be enabled.

Ciao
Peter
Attachment #410471 - Flags: ui-review?(clarkbw) → ui-review+
Comment on attachment 410471 [details] [diff] [review]
Patch that allows to print only selection if user has selected some text - checked in.

This looks good, ui-r+

I'm a little worried that people will have accidentally selected text and only print out their selection as we don't really notify the user of this option being chosen.

Any ideas for helping the person at least once to know that we'll be choosing the selection by default?
fix checked in, thx, Tobias. We could ask for confirmation from the user, I suppose, the first time this happens...what do you think, Tobias?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1a1
Assignee: nobody → tokoe
Print selection function is still disabled with the 20100113 nightly trunk build (3.2a1pre). 

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100113 Shredder/3.2a1pre ID:20100113033308
yes, but if you select some text in the message, and then print, does it print just the selected text?
Yes it works with:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100113 Lightning/1.1a1pre Lanikai/3.1a1pre ID:20100113040636
Yeah it prints with just the selected text. Would the 'print selection' button in the print box be implemented too?

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100113 Shredder/3.2a1pre ID:20100113033308
(In reply to comment #90)
> Yeah it prints with just the selected text. Would the 'print selection' button
> in the print box be implemented too?
Not without a fair amount of work - please see #c75 for the difficulties involved.
Sorry folks but this fix just duplicates the work of the PrintingTools extension without the bells and whistles. I would be extremely concerned that if this patch is implemented in the release version of Thunderbird it will lead to user confusion and interfere with the operation of the PrintingTools extension. To me it would be better to implement this as another, alternative to PrintingTools, extension for those who want it. 

I have not been able to test if it conflicts with PrintingTools as I have no idea where to download the more advanced version of Shredder mentioned in comments above (Shredder/3.2a1pre ID:20100113033308). I have the latest version of Shredder/3.0.2pre.

I agree with Comment #71. It is a basic function that needs to be fixed, no matter how complicated it may be. With all due respect to the hard work done by Tobias this is a "work around" not a fix for the problem.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100113 Shredder/3.0.2pre
(In reply to comment #92)
> Sorry folks but this fix just duplicates the work of the PrintingTools
> extension without the bells and whistles. I would be extremely concerned that
> if this patch is implemented in the release version of Thunderbird it will lead
> to user confusion and interfere with the operation of the PrintingTools
> extension. To me it would be better to implement this as another, alternative
> to PrintingTools, extension for those who want it. 

Really?  I think it is more important to have something working in the actual Thunderbird install than to be concerned about a third party extension.
can we move this ongoing work to a new bug or newsgroup please?
(In reply to comment #94)
> can we move this ongoing work to a new bug or newsgroup please?

I disagree.

The Status of this bug needs to be changed to REOPENED.

The "solution" so far is a "work around" for the problem and is not a fix. Please note that the original long standing bug has not been resolved. 

As mentioned in comment #2
> To reproduce, open MailNews, select a message in the threadpane, select text in 
> the message preview pane (at the bottom), and File > Print.  The `Selection' 
> radiobutton is disabled. 

The only real solution is to get the radio button working. 

This bug has been mentioned by many people and to close this thread and open a new one loses the history and ongoing comments.
sure, I erred in marking it fixed. I'll re-open this. Contributions for fixing this so that print selection is enabled are very welcome.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #410471 - Attachment description: Patch that allows to print only selection if user has selected some text → Patch that allows to print only selection if user has selected some text - checked in.
Whiteboard: [workaround checked in - selection is always printed, if there is a selection]
hello,

my uncle have the same trouble on windows
and me on GNU/Linux Ubuntu
i am not programmer
is it a programmer can fix this bug ?
my uncle will want to install outlook

thanks
Bertrand
Bertrand, This is a very old bug with extensive comments.  Take a look at comments 75 and 76: https://bugzilla.mozilla.org/show_bug.cgi?id=66806#c75 and https://bugzilla.mozilla.org/show_bug.cgi?id=66806#c76 .

What they indicate, in a nutshell, is that, as often is the case with computers, something that seems trivial from a user's perspective (all of us), may require extensive programming to fix.  If it was easy, I'm sure an annoyance of this magnitude would never have made it out the door or would have been fixed right away.

In the mean time, I wish there was a working programmer's bounty system where we could collectively put up some cash to entice someone to work on this.  I know I would put up at least $20 because I would use this feature all the time.

For now, someone put in a patch that should be in all recent versions that automatically prints just the selection if one has been made.  I haven't tried it because I use the PrintingTools 0.2.9 Thunderbird Extension which does the same thing as one of its options.

HTH

Joe
(In reply to comment #98)
> 
> For now, someone put in a patch that should be in all recent versions that
> automatically prints just the selection if one has been made. 

That patch is only in 3.1; it's not in the 3.0.x builds.
Hello folks
This bug really needs to be resolved. Is it possible to move the status up to blocking for TB 3.3? This way it may get some attention from someone with the skill to address the issue.

Sorry but I personally do not have the necessary skills.
(In reply to comment #85)
> Comment on attachment 410471 [details] [diff] [review]
> Patch that allows to print only selection if user has selected some text -
> checked in.
> I'm a little worried that people will have accidentally selected text and only
> print out their selection as we don't really notify the user of this option
> being chosen.
> 
> Any ideas for helping the person at least once to know that we'll be choosing
> the selection by default?

Bug 650506 explains one idea...: in the print dialogue, let's just tune the print range radioboxes correctly to show that we'll print the selection (and can't print anything else in that situation, until this bug gets fixed)
I've been following this bug for quite some time.  I'm unclear about the work-around patch status.  Is it actually in Thunderbird now, and if so, starting at what release number?

I use the printing tools extension (which also has a few other nice features), so I can't (easily) tell by just trying it.

Like others on this thread, I feel it should still be fixed in TB itself and that it should be a priority.  I would also contribute to a bounty for it, but it seems that no one has time or inclination to set one up.

Maybe we need a bounty to set up a bounty system <G>!
(In reply to comment #103)
> I've been following this bug for quite some time.
> 
> I use the printing tools extension (which also has a few other nice features),
>

I too have been following this bug for some time and I also use the Printing Tools extension. IMHO any patch that emulates but does not do everything that a recognised extension does is not worth implementing. This is with all due respect to the writer of the patch.

Please! somebody with the appropriate skills take this on.
It's not in Thunderbird 3.1.9 which is the last update I have.
It is now 11 years since this bug was opened, and it still has not been sorted. Am using thunderbird 7.0.1 for Suse Linux 11.4, print selection still unusable.
This is interesting: Printing from composition has the correct behaviour!
(I'm on TB's Aurora channel, currently at 9.0a2, 2011-09-30, using Windows 7 Starter)

For someone with more code knowledge than me, this should make it a lot easier to track down the problem of this bug in the code: Compare / track down the two different print routines (composition vs. received msg), and this bug must be among the differences (there shouldn't be too many differences between the two routines, I assume?).

STR 1 (for wrong behaviour, this bug)

1) view received msg (wherever you please)
2) select some text from msg body
3) Ctrl+P to print
4a) Select Print range "Everything" (preselected), confirm to print
4b) Select Print range "Pages", confirm to print
4c) Try to select Print range "Selection"

Actual result for STR 1 (bad)

After 3):
- Print dialogue shows up
- Print range "Selection" is disabled (this bug, and bug 650506)
- Print ranges "Everything" and "Pages" are enabled (wrong, see bug 650506)
- Print range "Everything" is preselected (this should be changed to "Selection", even before fixing the backend for this bug, see bug 650506)

After...
4a) "Everything": We don't print "Everything" (read: all pages of the message), we currently force-print the selection (due to the workaround for this bug - good for now, but not reflected in the UI).
4b) "Pages": We don't print "Pages of the message": due to the workaround, we force-print "pages of the selection" instead (what a sophisticated feature for multi-page selections! But alas, unexpected...)
4c) "Selection": n.a. (disabled), but that's what we actually print

Expected Result for STR 1 (bad behaviour):
- same as Expected Result for STR 2 (good behaviour, see below)

 
And, for comparison:

STR 2 (for correct behaviour in composition, possible workaround for printing selections with mail headers)
1) compose msg (forward existing msg inline to print selection plus mail headers)
2) select some text from msg body
3) Ctrl+P to print
4a) Select Print range "Everything" (preselected), confirm to print
4b) Select Print range "Pages", confirm to print
4c) Select Print range "Selection", confirm to print

Actual result = Expected result for STR 2 (good)

After 3):
- Print dialogue shows up
- All print range options, including "Selection"(!) are correctly enabled (Everything / Pages / Selection)
- Print range "Everything" is preselected (this should be changed to "Selection")
After...
4a) Everything (all pages of msg) print as expected
4b) Specified Pages of msg print as expected
4c) Current Selection prints as expected(!) (well, in my test case of a multi-page selection, 1st line of selection is cut off at the top, but that's another problem which doesn't belong here)
Keywords: useless-UI
Summary: Print selection is always disabled for MailNews messages → Print selection is always disabled for MailNews messages (only composition has correct behaviour)
As a sidenote to everyone:

For bugs with 95 votes and more than 100 comments, let's not wait for comment 107 until we make sure that we actually have precise descriptions of STR, Actual Behaviour, and Expected Behaviour!

As seen in comment 107, following the prescribed format might actually help to understand better what's going on and thus contribute to faster fixing!
Whiteboard: [workaround checked in - selection is always printed, if there is a selection] → [current STR & behaviour in comment 107] [ugly workaround checked in - selection is force-printed, if there is a non-composition selection]
IIRC there is an earlier comment that details that during composition Thunderbird has everything it needs for Print Selection to work, but when just viewing a message, the code takes a very different approach and does not have the message in a usable form to extract a selection.  This is a major reason for the long-standing nature of this bug.  It needs substantial coding to fix.

Needless to say, it still ought to be done.  It's way too long for a basic usability flaw to persist.  Of course, it's free software and someone with sufficient expertise will have to volunteer to fix it since nobody seems to have a bounty system that actually works.
Ludovic, some questions to move this forward:

In view of the new findings of comment 107 which might make it easier to fix this (correct behaviour exists in composition!):

1) How to get [uxprio] for this bug? Considering
- 95 votes
- 12 duplicates
- more than 10 years old
- more than 100 comments
- works in FF (with some flaws like cutting off a line at the top)
- printing seems basic enough a functionality that it should work without workarounds and misleading UI?

2) Who might be knowledgeable/willing to look at the underlying print-related code (e.g. printutils) so that we can CC those people on this bug?

3) Shouldn't we set some more flags on this? Like
status-thunderbird8: affected
status-thunderbird9: affected
tracking-thunderbird9: ?
new target milestone (currently at 3.1a1)?
Not surprisingly, many people on getsatisfaction also have this problem (currently 32 people on various reports, I didn't finish all the merging)

I declared this report canonical:
http://gsfn.us/t/rx5n

All of them are here:
http://getsatisfaction.com/mozilla_messaging/tags/bug_66806
Whiteboard: [current STR & behaviour in comment 107] [ugly workaround checked in - selection is force-printed, if there is a non-composition selection] → [gs] [current STR & behaviour in comment 107] [ugly workaround checked in - selection is force-printed, if there is a non-composition selection]
(In reply to Thomas D. from comment #107)
> This is interesting: Printing from composition has the correct behaviour!
...
> For someone with more code knowledge than me, this should make it a lot
> easier to track down the problem of this bug in the code: Compare / track
> down the two different print routines (composition vs. received msg), and
> this bug must be among the differences (there shouldn't be too many
> differences between the two routines, I assume?).

The "differences" are that the composition window doesn't print message headers e.g. to & subject. Therefore it isn't quite the "correct" behaviour, and doesn't actually help to fix this bug.

Hence comment 75 still applies to fixing this bug.

(In reply to Thomas D. from comment #110)
> 2) Who might be knowledgeable/willing to look at the underlying
> print-related code (e.g. printutils) so that we can CC those people on this
> bug?

afaik we don't have anyone specific who knows printutils. I'm assuming Tobais isn't working on this though, so I've taken him off the assigned and set up helpwanted.

> 3) Shouldn't we set some more flags on this? Like
> status-thunderbird8: affected
> status-thunderbird9: affected
> tracking-thunderbird9: ?

No, they are only for branch tracking when there's special circumstances.

> new target milestone (currently at 3.1a1)?

I've reset that to the default - we don't generally use those in bugs for tracking before a bug is fixed.
Assignee: tokoe → nobody
Flags: wanted-thunderbird+
Keywords: ux-discoveryhelpwanted
Priority: P4 → --
Target Milestone: Thunderbird 3.1a1 → ---
So long, and thanks for all the fish (and Tobias for his earlier work), I've been watching this bug for about 7 years now and it's almost 12 years old.  Time to remove myself from CC...
11 years... sorry, it's very late...  Good luck to whoever has the time and skills to sort this out, I'll buy you a drink.
(In reply to Thomas D. from comment #107)
> This is interesting: Printing from composition has the correct behaviour!
> (I'm on TB's Aurora channel, currently at 9.0a2, 2011-09-30, using Windows 7
> Starter)

Sadly, what used to work correctly according to my comment 107, is now broken:

It's no longer possible to print selections from the composition window (both current tb10.0.2 and trunk, on Windows XP). Selecting "Selection" from the print dialogue will still print the whole draft instead of selection only.

So instead of improving, this is actually getting worse.
With respect to understanding this bug better, it would be interesting to know what caused this new regression between aurora tb9 and release tb10?
(In reply to Thomas D. from comment #115)
> (In reply to Thomas D. from comment #107)
> It's no longer possible to print selections from the composition window
> (both current tb10.0.2 and trunk, on Windows XP). Selecting "Selection" from
> the print dialogue will still print the whole draft instead of selection
> only.

I got tricked by the bad interaction of my testcase with TB's wrong behaviour, so above description isn't accurate.

My testcase has 20 lines like this one:
hello world this is a test case 1111111111 2222222222 3333333333 4444444444 5555555555 6666666666 7777777777 8888888888
It's important that the line is longer than a line which fits on A4 vertical printout.

So I selected starting from "this" in line 2 up to "7777777777" in line 18.
My printout then started with "hello" (instead of "this") and ended with "4444444444" (instead of "7777777777") and, due to the reformat for printing, appeared to have 20 lines (or more).

What really happens is this:

- we reformat the document for printing, where lines are shorter
- from the reformatted document, we print from the complete reformatted line which contains the beginning of the selection, to the complete reformatted line which contains the end of the selection.

The net result is that we print more than just the selection, which is unexpected, confusing, and potentially harmful in terms of privacy.
We should just print exactly what has been selected, as we do for selections in msg reader.

> So instead of improving, this is actually getting worse.
> With respect to understanding this bug better, it would be interesting to
> know what caused this new regression between aurora tb9 and release tb10?

So I'm not entirely sure if this regressed. Maybe I just didn't see this flaw when I tested for comment 107.
Blocks: 650506
Blocks: 655657
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Still the same problem. So far I use a plugin called printing tool, that could be configured to print selection only. But that's no longer working with 68 and dev says, he will not update because of change in plugin architecture.

I can confirm as well. I find it odd that something so simple has been a missing feature for so long. Get's annoying when I need to print certain sections of emails and have to copy and paste it into word or something to print it. Or clicking on FW to do it from there is just strange. This has been such a common feature in programs like this since I can remember.

(In reply to James from comment #120)

I can confirm as well. I find it odd that something so simple has been a missing feature for so long. Get's annoying when I need to print certain sections of emails and have to copy and paste it into word or something to print it. Or clicking on FW to do it from there is just strange. This has been such a common feature in programs like this since I can remember.

Odd indeed. Sorry for the inconvenience. As a workaround, select text to print, then just print using print area: "All/Everything", and it will print the selection only. Not very discoverable, and reverse bug of this; but at least you can just print your selection (from 3-pane; printing selection works for composition on release, fails on trunk). To print all pages, remove selection first.

See Also: → 1731183
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: