User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

Steps to reproduce:

I selected part of email body to print, then pressed Ctrl + Shift + P to print using the system dialog.

Actual results:

The "selection" option is disabled.

Expected results:

The "selection" option used to be enabled and allows printing the selected text only.

Does this happen with each and every email? Does this happen with both HTML and plain text emails? Which GTK version is being used?

Print selection isn't currently available in version 91.

Perhaps we only need to port Bug 140718 - Add a "Print selection only" menu item to the context menu when there is a selection ?

More generally, there is also

• Bug 1722943 - Consider allowing users to select and copy text from print preview
• Bug 1685476 - Print selection via context menu & via the new modal is not reflected inside the system dialog

Under the More settings Firefox has Format: Original/Selection/Simplified.
Geoff, was there a reason we couldn't have that?

(In reply to Andre Klapper from comment #1)

Does this happen with each and every email? Does this happen with both HTML and plain text emails? Which GTK version is being used?

It happens with every email, HTML and plain text. I've just had a friend try it on his computer and he has the option. I am using Linux, he's on windows 10. I am currently on version 91.1.1, build ID 20210916142849. I am not sure what you mean by GTK version!

I can print selection on Firefox just fine.

Printing selections has been a long-standing problem in Thunderbird, see bug 66806. About time to fix this!

Also, even when we print selection, we have never bothered to do it the right way so that the UI will know - bug 650506.

(In reply to Wayne Mery (:wsmwk) from comment #2)

Print selection isn't currently available in version 91.

Perhaps we only need to port Bug 140718 - Add a "Print selection only" menu item to the context menu when there is a selection ?

(In reply to Wayne Mery (:wsmwk) from comment #3)

More generally, there is also

• Bug 1722943 - Consider allowing users to select and copy text from print preview
• Bug 1685476 - Print selection via context menu & via the new modal is not reflected inside the system dialog

(In reply to Thomas D. (:thomas8) from comment #6)

Printing selections has been a long-standing problem in Thunderbird, see bug 66806. About time to fix this!

(In reply to Thomas D. (:thomas8) from comment #7)

Also, even when we print selection, we have never bothered to do it the right way so that the UI will know - bug 650506.

Surely, between these 5 bugs, a solution can be found.

Lots of things wrong with 91 and Print. Perhaps the worst I've ever encountered. So bad I've got to keep a version of 78 just to print.
When looking at issues with this new Print perhaps we need to list known problems, just in case they are inter-dependent?

In my case Ctrl+Shift+P does nothing whether you select text or not.
But regardless I'm confirming unable to choose what is printed. No ability to select and print desired text.

Menu app icon > Print or Ctrl+P opens a Print form but only shows the full text.

However, the new preview of Print offers No control at all over contents of the various parts of the headers or footers. Only show or not. Need to control content with same abilities as in versions of 78* and prior.
See bug 1731601

Worst issue is that the Print form cannot be manually moved and it covers all content of tabs and if the 'Menu Bar' is not enabled then you have no access to eg: Help
This desperately needs to be in a new window as it prevents all access to everything in Thunderbird whilst that Print form is open.
If one 'Print' option is selected then you cannot select another email to print, so creating a stack of separate windows showing all the various Print Preview windows which you will want to print as a later job. You are stuck and focused on one print which has now blocked all access to Thunderbird until you Print.
See Bug 1731606

All of these issues are identical problems in Firefox so I do not know why we are using Firefox code as it has now caused same problem in Thunderbird.

Options: create screendumps which you can edit and then put into a program that offers more control over what gets printed.

workaround: download and install a version of 78 and use on copy of profile to print what is required.

Can someone please set the "Priority" and "Severity" fields to their highest settings? Thank you.

Printing selection didn't work on 78 either, in fact it never did - bug 66806. We actually may want to dupe this there.

The printing code got a significant facelift for 91. Printing selection was apparently not implemented in Firefox when we synced up with their code. It should be possible to implement it now. We'll get back to this bug, but I think your tone above isn't exactly louring people into the area...

All of these issues are identical problems in Firefox so I do not know why we are using Firefox code as it has now caused same problem in Thunderbird.

Because overall it's a way much better state? And we'd have to re-implement printing completely on the Thunderbird side (with the old code getting thrown out). At the end of the day, printing - while it should work - is not really a Thunderbird core chore. Printing is something that the platform mostly should provide, and that's what it's doing.

(In reply to Magnus Melin [:mkmelin] from comment #11)

Printing selection didn't work on 78 either, in fact it never did - bug 66806. We actually may want to dupe this there.

The printing code got a significant facelift for 91. Printing selection was apparently not implemented in Firefox when we synced up with their code. It should be possible to implement it now. We'll get back to this bug, but I think your tone above isn't exactly louring people into the area...

All of these issues are identical problems in Firefox so I do not know why we are using Firefox code as it has now caused same problem in Thunderbird.

Because overall it's a way much better state? And we'd have to re-implement printing completely on the Thunderbird side (with the old code getting thrown out). At the end of the day, printing - while it should work - is not really a Thunderbird core chore. Printing is something that the platform mostly should provide, and that's what it's doing.

I just installed 78 and can confirm the selection option is greyed out, but if you had something selected, it would only print the selection regardless. At least that's the way it's been with Print to PDF which I used every day before the upgrade to 91. I juat didn't notice the option was disabled when it worked despite that.
Firefox works, the option is enabled and does what it claims.

Print Selection

In version 78.14.0
I can highlight text in email and use 'Print Preview' either via right click drop down menu or via Menu app icon > Print > Print Preview to see only the text I selected. So I can print what I select in version 78*
result: Pass

In version 91.1.1
Highlight selected text in email - use right click and select 'Print' or choose 'Print' via menu app icon to actually open 'Print Preview' and selected text is not displayed, all the email content is displayed.
Result: Fail

On a related note: Why does version 91* have a 'Print' option which is not a 'Print' option because it is a 'Print Preview' option.
Should the menu item currently called 'Print' be correctly renamed as 'Print Preview' to stop confusion.
Maybe this should be a separate 'enhancement' bug report.
Bug 1732511

Is the failure of print selection related to the failure to insert a selected quote in the compose window, or is that another bug in this version.

The current workaround options in Thunderbird 91* are clunky:
Highlight the selected text and use 'Reply' and then use the File > Print to open - you do not get the email headers but you do get the Subject in the header section and all selected text is the only text shwon in Print Preview.
The other option is open the 'View Source' and copy paste required headers and text into a new Write compose window and then use File > Print.

Note: By using the 'Write' window in both of the above workarounds also correctly opens the Print Preview in a new window, so does not block access in general to Thunderbird which is currently a problem when printing email from the Message Pane.

Whether the right click offers the option of 'print selected text' or whether the 'Print' Preview option goes back to working as it always has done - the point is the option needs to be available.

You can also use the "Snipping Tool" in Microsoft Windows to do some printing selections.

I have investigated and even if we really wanted to, this cannot be fixed for mail messages in Thunderbird 91.

It's not just messages - the calendar print has problems.
For reference selecting events Bug 1732734 date list bug 1732740

So far, it seems all of the large list of bugs are not going to get fixed, so why are we using this broken code?
Why not go back to options that may not have been perfect but were significantly better in many ways?

Why not go back to options that may not have been perfect but were significantly better in many ways?

Because the print engine from Firefox, upon which we rely, has been heavily revised and it doesn't provide this type of capability. And the old engine isn't a viable option because it will be going away.

(In reply to Wayne Mery (:wsmwk) from comment #20)

Why not go back to options that may not have been perfect but were significantly better in many ways?

Because the print engine from Firefox, upon which we rely, has been heavily revised and it doesn't provide this type of capability. And the old engine isn't a viable option because it will be going away.

Am I understanding that all the faults in Printing and that includes all the faults in the Calendar printing which are actually even worse and have more of an impact eg: cannot print any event or task prior to june 2021 - cannot print selected events only all events within a time frame providing none of them are prior to june 2021 - all of these problems - nothing can be fixed because Firefox developers are either incapable or do not care about Thunderbird specific requirements or they do not understand that Thunderbird does not operate or have same needs as Firefox browser.

This situation is not very healthy.
Has this situation arisen due to a lack of communication with the Firefox developers, perhaps they are simply not aware of the problems.

What I mean to ask is: Did meaningful discussions between Thunderbird developers and Firefox developers and any other party/council member take place before the revising of the print engine, so Firefox developers were fully aware of all the printing requirements required by Thunderbird, thus ensuring Thunderbird's printing needs would be included in the revised print engine?
If yes, then what went wrong. If no, then why no communication?

The things you cannot do when printing calendar things are not related to this bug. They are just a lack of a user interface to do what you want. That can be fixed. This bug cannot be fixed because it requires the ability to get information from a document which is not available.

This issue has nothing to do with the council. Firefox engineers are paid to work on Firefox and we don't get to make demands of them. We do talk to them and most are cooperative well beyond their job description. However we can't ask them to foresee a bug which has only now come to light months after the code has been released.

This bug cannot be fixed because it requires the ability to get information from a document which is not available.

The email is downloaded, the text is selected.
Can you explain what you mean by the document is not available?

See: http://forums.mozillazine.org/viewtopic.php?p=14905418#p14905418

(In reply to Anje from comment #15)

The current workaround options in Thunderbird 91* are clunky:
Highlight the selected text and use 'Reply' and then use the File > Print to open - you do not get the email headers but you do get the Subject in the header section and all selected text is the only text shwon in Print Preview.

For simple text messages, this works, as does Edit as New Message.

However, when doing this for HTML formatted messages, all table and other elements are enclosed in dotted red lines, to help with editing. Is there a way to suppress the display of these dotted red lines, for printing?

(In reply to Geoff Lankow (:darktrojan) from comment #17)

I have investigated and even if we really wanted to, this cannot be fixed for mail messages in Thunderbird 91.

Yet the option apparently exists in printing tools NG Beta3addon. I am seeing it offered in support as an alternative for folk looking for this functionality. Not that I can make it work.

(Sorry for the early mistaken attribution Geoff)

(In reply to alta88 from comment #28)
Please - once again - keep a respectful tone. This is far from ok! If you think something was overlooked, it's easy enough to point out what without being disrespectful.

And since this is open source, you already said fixing will be incredibly easy: I'm assuming you'll provide a patch? This is open source.
With the poisonous comments, that's your window to fix it. Why would anyone want to go near this area after your attacks?

Why did you NI me?

Too numerous to count things get broken or removed and it's usually pointless to comment. But when obvious misinformation like "it cannot be fixed" is used as an excuse, often to reporters who can't possibly rebut the claim, be prepared for bluntness regarding the quality of development on this project. Especially given the resources available to it.

Your preference to take offense at criticism rather than at a regression making it to release is unfortunate.

I'm assuming you'll provide a patch?

The offer -- to allocate my time, pro bono, to make up for errors and omissions by paid staff -- is declined.

However, I will repeat, the (a) fix is easy and the first step is to reopen this bug. Why would anyone go near a WONTFIX.

Hi Geoff, I have a technical question here (along what Anje has aptly asked, but she didn't put a needinfo...):

• Iiuc, we are now printing directly from the document, i.e. the message as shown in message reader.
• We are using (almost) the same method of printing as Firefox.
• Firefox has no problem to print selected text from the currently shown document, it will dynamically offer an option called Selection (vs. Original/Simplified) in the Format section (and show the Format section itself if it wasn't shown before).
• So where exactly is the challenge of printing a selection from the currently displayed document (which is definitely available), in pretty much the same way that Firefox does this? (In fact, as evidenced in and in spite of Bug 66806, TB 78 already had the fully correct flow for composition because we were not using an intermediate document there...)

(In reply to Anje from comment #23)

This bug cannot be fixed because it requires the ability to get information from a document which is not available.

The email is downloaded, the text is selected.
Can you explain what you mean by the document is not available?

I have the same question! It would appear that the displayed email including the selection is available for direct printing (also of selection, as in FF), no? I understand that before we changed things in printing, we had a hidden print document that may not have been available, but now?

I just realize that the current STR of comment 0 are not very useful as they seem to describe an exceptional pattern (Ctrl+Shift+P) on Linux, if at all. Also, this bug shouldn't be primarily about using the System Print dialog, it's much more about the new FF-style print dialog.
For Windows at least (majority of TB users), Ctrl+Shift+P doesn't exist as a shortcut.

I'll provide better STR and more background in the user story at the top of this bug.

In comment 29 and the top story is mentioned
tools NG Beta3

what shall do my printing.

I cnanot find this tool / add-on anywhere.
Can somebody help me pls?

Thanks

It is Printing Tools NG.

The developer states:

"New 78 Update with compatibility for 89
Note: NOT COMPATIBLE With 9X.X yet
working on it"

thank you very much!
I bookmarked it and wait unpatiently.

(In reply to Thomas D. (:thomas8) from comment #34)

Hi Geoff, I have a technical question here (along what Anje has aptly asked, but she didn't put a needinfo...):

• Iiuc, we are now printing directly from the document, i.e. the message as shown in message reader.
• We are using (almost) the same method of printing as Firefox.
• Firefox has no problem to print selected text from the currently shown document, it will dynamically offer an option called Selection (vs. Original/Simplified) in the Format section (and show the Format section itself if it wasn't shown before).
• So where exactly is the challenge of printing a selection from the currently displayed document (which is definitely available), in pretty much the same way that Firefox does this? (In fact, as evidenced in and in spite of Bug 66806, TB 78 already had the fully correct flow for composition because we were not using an intermediate document there...)

(In reply to Anje from comment #23)

This bug cannot be fixed because it requires the ability to get information from a document which is not available.

The email is downloaded, the text is selected.
Can you explain what you mean by the document is not available?

I have the same question! It would appear that the displayed email including the selection is available for direct printing (also of selection, as in FF), no? I understand that before we changed things in printing, we had a hidden print document that may not have been available, but now?

The problem that I discovered is that Firefox has disabled printing from parent process windows, which we use to display mail but they don't use to display web pages. However I didn't dig deep enough and learn why they did that. It turns out they had a trouble getting it to work and decided they just didn't need it. Which is rather unhelpful for us. I managed to fix it and assuming bug 1740630 lands as expected, it'll be fixed for us too.

That's awesome Geoff, thanks for rapid reply and corrective action. Less than two hours after my enquiry in comment 34 (which mirrors Anje's question of comment 23), Geoff has filed bug 1740630 and provided a patch which will fix this.

CURRENT STATUS OF THIS BUG: READ THIS BEFORE COMMENTING

Thank you to everyone who reported this bug and took action to get the Thunderbird printing UX improved!

I apologize for the inconvenience caused by this bug. For good reason, we (Thunderbird) are using toolkit/FF code for printing, and that code had changed for TB 91 to deliver a better, unified print experience, in turn requiring substantial adaptations on the Thunderbird side, which unfortunately didn't restore some relevant convenience features.

This problem is now well-understood and we're fixing it in bug 1740630. We must follow procedure so that we don't break other things in the process, so that may need a couple of weeks, but we'll uplift this into TB 91 release channel asap. In the meantime, let's keep the volume low and refrain from me-too/negative/pushing comments especially on the other bug, so that devs can focus on getting their work done.

(In reply to Thomas D. (:thomas8) from comment #40)

This problem is now well-understood and we're fixing it in bug 1740630.

Just noticed this. That bug is now fixed, so does that mean this one should be also? Are there other printing bugs/issues? It seems very slow to bring up the print window for sure (Windows 10).

Thanks.

thanks for your comment
version 91.3.2.
Unfortunately the problem is not solved. Und furthermore it is a "2 bugs in on wish":

"strg + P" does NOT print the selection in the mail as before, but opens the system printing dialog instead.

Within the system printing dialog the option "selection" works for the first time of calling it, after that it is greyed out.
So I cannot "print 2 selections of text in a row" with Thunderbird at all. This is annoying.
I have to copy them in another program or I have to print the complete text.

Fixed by bug 1740630.