User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

A user reports PRINT no longer works.

I tested with Build ID: 20200305093511 and with the previous build on Ubuntu 18.04.3 LTS and see the same problem.

Select a message in the Thread Pane.
Select Print from the menu.

Actual results:

No response from the printer.

Print manager application indicates that there are no active jobs.

Expected results:

Message should have been printed.

Just tried printing from Print Preview using a new test profile with Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Thunderbird/75.0a1 Build ID 20200305093511 and find this in the Error Console.

No problem printing from 74.0b2 or 68.5.0.

Someday I might learn how to do regression testing.

Anyway in my testing I found:

Printing works using 75.0a1 Build ID 20200214134252
Printing stopped working with 75.0a1 Build ID 20200215105505

If printing is totally broken, it will certainly impact beta users.

Could this have broken by Bug 855889 - Remove "print.use_global_printsettings" pref ?

It could as it is in the time frame but a local back-out didn't didn't solve the issue.

In that case, perhaps Bug 1552966 ? - Convert the printing code from DocShellTree* to BrowsingContext - from https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2020-02-14+04%3A00%3A00&enddate=2020-02-15+10%3A00%3A00

https://hg.mozilla.org/comm-central/pushloghtml?startdate=2020-02-14+04%3A00%3A00&enddate=2020-02-15+10%3A00%3A00

Yes, backout of bug 1552966 let me print again.

For messageWindow.js (the standalone msg win), the below seem to work (help). But not for the 3pane.

case "cmd_print":
let browser = getBrowser();
PrintUtils.printWindow(browser.browsingContext);

I suspect something is wrong with the docshell stuff in nsMsgPrintEngine.
I wonder if we could get rid of nsMsgPrintEngine completely...

https://hg.mozilla.org/mozilla-central/rev/33a086f16245
Ben, bug 1552966 comment 2 also could be worth a read.

two dupes within 2 two working days of releasing the beta (~6k-8k? users) is an interesting indication of the importance of printing.

I think it's a lot more than 8k users, here we have more than 60 users, and nobody can print who has the latest 75b1 version.
Let's hope Mozilla will fix this soon, as a lot of us wants to print out e-mails on a daily basis!
(Maybe they got a donation from Green Peace to not waste paper... x))

How long will it take for them to correct this printing issue. It's been almost two weeks and still no response.

(In reply to Aron.Somodi@gmail.com from comment #12)

I think it's a lot more than 8k users, here we have more than 60 users, and nobody can print who has the latest 75b1 version.

That is only the number of beta users at version 75 at the time of posting, which I was citing to help development to gauge the potential impact. That's only 10% of our beta population

Let's hope Mozilla will fix this soon, as a lot of us wants to print out e-mails on a daily basis!

That this probably impacts many userswas part of my point. But please understand, Mozilla does not drive this train - the drivers are "Who we are".

To detail the current situation - the attention given thus far is comment 7, an assessment of P1+critical (doesn't get much higher than that), and a developer assigned so the next step depends on how this fits into Ben's priority list. Please know that if your 60 users depend on printing and other critical functions that beta might not be a good place for them, as much as we dearly love to have beta users.

Preliminary findings, printing from the 3 pane window under gdb:

There's an openDialog() call which fails ("Chrome windows may never have content windows as their openers."). My guess at the moment is that this is happening in comm/mailnews/base/content/msgPrintEngine.{xhtml|js] (which, I think, is trying to open a new window containing that message, to print from).
So the print operation aborts before it even starts. That's the first thing to fix.
I'm a bit hazy on the whole chrome-vs-content docshell issue, but I'll dig into it.
Beyond that there may also be some DocShell -> BrowsingContext work. And hopefully some code removal (nsMsgPrintEngine!) We'll see.

Just an update on what I've discovered and tried out so far:

(In reply to Ben Campbell from comment #15)

There's an openDialog() call which fails ("Chrome windows may never have content windows as their openers."). My guess at the moment is that this is happening in comm/mailnews/base/content/msgPrintEngine.{xhtml|js] (which, I think, is trying to open a new window containing that message, to print from).

Turns out that It's not the msgPrintEngine.xhtml window that's failing down in openDialog(). It's failing when the printing system tries to pop up the progress window. So the print preview works OK, but actual printing doesn't (printing dies during the call to Print() here: https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgPrintEngine.cpp#552 ).

I had a go at bypassing the C++ code in nsMsgPrintEngine.cpp altogether, and just use PrintUtils.printWindow(), but then I figured the C++ was probably doing some print-specific rendering which we'll need to keep. I've got some other ideas to try out.
In the long term, I think it looks like PrintUtils.printWindow() is the way to go. PrintUtils has some comments in it which seem to imply it's the preferred entry point for printing.

Ben, do you have sense of whether a safe patch is likely to be forthcoming by Wednesday or Thursday? If so, then we'll wait on creating the beta, and if not, then we won't wait. No pressure - just coordinating activity.

I'm going to have another go at it today, but I can't promise anything - I'd give it a 50% chance of working.

(Sorry to be so wishywashy on this but I'm a bit out of my depth - the issue is squarely down in the GUI code, which I'm pretty unfamiliar with. Stuff I obviously need to get familiar with, but it'll take a bit more time to wade through)

Just spent another frustrating day on this. Will give it another couple of hours first thing tomorrow morning to see if a fresh look shakes anything loose, but not looking too likely at this point.

I'm staying with version 74 until this issue has been resolved.

OK. Here's a workaround. It's crappy and stopgap, but all I could come up with for now.
It simply forces the progress dialog to be suppressed.

Seems to work for me - I managed to print out a selected message in the 3pane view, and an address book.

I guess if we go with this we open another bug "No progress dialog during printing" (which is likely to turn out to be "rethink the whole printing system" ;- )

Further thoughts on printing:

I've single-stepped down through every line under nsMsgPrintEngine::PrintMsgWindow() to the progress dialog assert. The problem is that the docshell for our document is a "content" one, rather than "chrome". And so the progress dialog fails to open (because it's a "chrome" window, which can't be opened from "content" ones). Maybe some hacking in our printengine layout (mailnews/base/content/msgPrintEngine.xtml) would help... or maybe nsDocumentViewer::Print() in M-C is just broken.

Next steps would be:

• Survey M-C to see how it handles printing. Does it still use nsDocumentViewer::Print()? Is nsDocumentViewer::Print() broken?
• See how PrintUtils.js works. Ideally we'd transition over to this, but we'd need to do a look of work on display stuff (probably treat printable things more like webpages, using different urls and/or css to craft a nice print version)...

Added Bug 1625299 to track backing out the fix in this bug :-)

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/c447fb3ea547
Disable print-progress dialog. It would fail to open and abort the print. r=mkmelin

When will the next beta be out to incorporate this change?

When will the next beta be out to incorporate this change?

Thinking 75.0b3 some time next week, timing unknown. If not then, 76.0b1 in two weeks.

Thunderbird 75b2 still has this bug - printing makes TB go into an endless loop.
74b2 had some bugs, but printing was perfect - this printing bug is at least two weeks old without a fix...
Who borked what? Why can nobody fix this, when it has always been worked- except during the past 2 weeks?
Please, fix it ASAP! Thanks a lot!

Would it be possible to either do the 75.0b3 now or just do a new build on 75.02b with the correction?

(In reply to Tom from comment #40)

Would it be possible to either do the 75.0b3 now or just do a new build on 75.02b with the correction?

The plan is already posted in comment 36 in response to your comment 35.

Thunderbird 75.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/12c9e9bca3f6

I saw the message said it was fixed but it is not, I still cannot print from Thunderbird with the latest patch, it just goes nowhere and hangs up. Is there a link to download an earlied version?

(In reply to Ray Valdes from comment #46)

I saw the message said it was fixed but it is not, I still cannot print from Thunderbird with the latest patch, it just goes nowhere and hangs up. Is there a link to download an earlied version?

Perhaps you are seeing a different symptom related to Bug 1626391 - Calendar events will not print (the preview is just blank)

(In reply to Ray Valdes from comment #46)

I saw the message said it was fixed but it is not, I still cannot print from Thunderbird with the latest patch, it just goes nowhere and hangs up. Is there a link to download an earlied version?

What version exactly? The workaround is in 75.0beta3, which isn't released just yet.

Sorry, I must have misread the last post, I have 75.0 Beta2

Did this bug fix disable printing from Print Preview?

That isn't working in
Name Thunderbird
Version 75.0b3
Build ID 20200330190334

Error Console output

Same here, it works with just the "Print" command but out od Print Preview it does not

I have 76.0 b1 and the print still does not work from the "Print Preview" screen. Is this still an issue being looked at?

This may be due to a regression in the platform code for printing. See https://bugzilla.mozilla.org/show_bug.cgi?id=1630095#c13

It turns out the cause of bug 1630095 was the setting of MOZ_FORCE_DISABLE_E10S in the environment.

Does Thunderbird run with e10s disabled? Or are the people that experienced this bug running with it disabled?

Thunderbird doesn't use e10s.