Closed Bug 1959171 Opened 21 days ago Closed 12 days ago

When printing a PDF attachment, only blank pages are being printed

Categories

(Thunderbird :: General, defect, P1)

Product:
Thunderbird
Component:
General
Version:
Thunderbird 137
Type:
defect

Tracking

(thunderbird_esr128 unaffected, thunderbird137 affected, thunderbird138+ affected)

Status:
VERIFIED FIXED
Milestone:
139 Branch
Tracking Flags:
Tracking Status
thunderbird_esr128 --- unaffected
thunderbird137 --- affected
thunderbird138 + affected

People

(Reporter: tim, Assigned: lsalzman)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

Sample email with PDF attachment
70.45 KB, message/rfc822
Details
SU-orig.pdf
313.37 KB, application/pdf
Details
SU-sent.pdf
73.99 KB, application/pdf
Details
Bug 1959171 - Guard against imbalanced clips in DrawTargetCairo. r?aosmond
48 bytes, text/x-phabricator-request
diannaS
: approval-mozilla-beta+
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

Print a PDF attachment.

Actual results:

Only blank pages are being printed.

Expected results:

The contents of the PDF attachment should have been printed.

Same if you print it to pdf? Sure the printer is working?
Can you attach a sample .eml that contains such an attachment?

Component: Untriaged → General

The issue also occurs when I print it to a PDF in Thunderbird. The PDF attachment prints correctly if I save it to my computer and print it using Adobe Acrobat.

I have attached a sample email.

I can confirm that on linux, Daily.
Prints fine on Firefox. Also prints fine on Thunderbird 128.

In the native console I got

[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0x76b3196be400, context 0x76b315070e00, status 0
[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0x76b3196be400, context 0x76b315070e00, status 0
[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0x76b30d01cf00, context 0x76b30e38aa00, status 0
[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0x76b30d01cf00, context 0x76b30e38aa00, status 0
[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0x76b302e7fd00, context 0x76b30e389e00, status 0
[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0x76b302e7fd00, context 0x76b30e389e00, status 0
Status: UNCONFIRMED → NEW
status-thunderbird137: --- → affected
status-thunderbird138: --- → affected
status-thunderbird_esr128: --- → unaffected
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
Duplicate of this bug: 1959736
Duplicate of this bug: 1959742

Can we get a regression range for this?

Flags: needinfo?(alice0775)
Priority: -- → P1

See the duplicate bug. It also removes most of the helper programs or whatever they are called, under settings.

Regression range: you mean when it last worked?
I only observed this issue yesterday, with 137.0.1;
not sure about 137.0, may not have printed anything then;
I am certain it worked fine with 136 (or whatever was last before 137.0).

Regressed by: 1950814

Thanks very much Alice.

This looks like a problem was introduced with the m-c update to pdf.js which happened in bug 1950814.

No longer regressed by: 1950814
Regressed by: 1950814

:calixte, any idea what's going on here?

Flags: needinfo?(cdenizet)
Keywords: regressionwindow-wanted

I just tried in the Firefox nightly containing that patch with the attached pdf and it works for me.
I can reproduce myself with daily on Windows 11.
As far as I can tell, the pdf.js update doesn't contain anything which could cause such a bug.
In looking at the pushlog, I'd say that:
https://hg-edge.mozilla.org/mozilla-central/rev/9cc733bde4acd05b9c2f228499534a31b283d1e7
is probably a better culprit.

:lee, what do you think ?

Flags: needinfo?(cdenizet) → needinfo?(lsalzman)

Yeah it's working in Firefox but not in Thunderbird - which is very strange. (Tried nightly/daily for both)

Regressed by: 1950596
No longer regressed by: 1950814

My work in bug 1959815 might resolve this. We can see after it lands.

Flags: needinfo?(lsalzman)
See Also: → 1959815

In case bug 1959815 does not help... would it help to "trap" the
print file generated by Thunderbird (the data sent to CUPS),
to be able to scrutinize?

Seems to be working with the 2025-04-12 daily build (which has the fix for bug 1959815)

Tim, does this still reproduce with the latest Firefox nightly build?

Flags: needinfo?(tim)

The issue only occurs in Thunderbird, not in Firefox.

Flags: needinfo?(tim)

comm-central debug build(20250413102421) crashes without crash report when printing pdf.

And Terminal output:

[Parent 9476, Main Thread] WARNING: '!ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo())', file /builds/worker/checkouts/gecko/dom/clients/manager/ClientSource.cpp:186
[Parent 9476, Main Thread] WARNING: '!ClientIsValidCreationURL(mClientInfo.PrincipalInfo(), aArgs.url())', file /builds/worker/checkouts/gecko/dom/clients/manager/ClientSource.cpp:66
[Parent 9476, Main Thread] WARNING: Failed to retarget HTML data delivery to the parser thread.: file /builds/worker/checkouts/gecko/parser/html/nsHtml5StreamParser.cpp:1215
[Parent 9476, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/comm/mailnews/local/src/nsMailboxService.cpp:410
[Parent 9476, WindowsVsyncThread] WARNING: DwmComposition dynamically disabled, falling back to software timers: file /builds/worker/checkouts/gecko/gfx/thebes/gfxWindowsPlatform.cpp:1754
[Parent 9476, Main Thread] WARNING: '!ClientIsValidCreationURL(mClientInfo.PrincipalInfo(), aArgs.url())', file /builds/worker/checkouts/gecko/dom/clients/manager/ClientSource.cpp:66
[Parent 9476, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/chrome/nsChromeRegistry.cpp:182
[Parent 9476, Main Thread] WARNING: 'NS_FAILED(rv)', file /builds/worker/checkouts/gecko/chrome/nsChromeProtocolHandler.cpp:73
[Parent 9476, Main Thread] WARNING: Failed to retarget HTML data delivery to the parser thread.: file /builds/worker/checkouts/gecko/parser/html/nsHtml5StreamParser.cpp:1215
[Parent 9476, Main Thread] WARNING: NS_ENSURE_TRUE(mCacheEntry) failed: file /builds/worker/checkouts/gecko/netwerk/protocol/http/nsHttpChannel.cpp:5416
[Parent 9476, Main Thread] WARNING: Invalid computed inline-size!: 'aComputedISize >= 0', file /builds/worker/checkouts/gecko/layout/generic/ReflowInput.cpp:408
[Parent 9476, Main Thread] WARNING: Invalid computed inline-size!: 'aComputedISize >= 0', file /builds/worker/checkouts/gecko/layout/generic/ReflowInput.cpp:408
[Parent 9476, Main Thread] WARNING: Caller should supply a printer name.: file /builds/worker/checkouts/gecko/widget/nsPrintSettingsService.cpp:921
[GFX3-]: Surface size too large (exceeds extent limit)!
[GFX2-]: Allowing surface with invalid size (Cairo) Size(67280,47600)
[9476] Assertion failure: mClipDepth > 0, at /builds/worker/checkouts/gecko/gfx/2d/DrawTargetCairo.cpp:1572
#01: DumpCompleteHeap[T:\mozregression\thunderbird\xul.dll +0x1c6d8f6]
#02: VR_RuntimePath[T:\mozregression\thunderbird\xul.dll +0x41b296c]
#03: VR_RuntimePath[T:\mozregression\thunderbird\xul.dll +0x3c17767]
#04: VR_RuntimePath[T:\mozregression\thunderbird\xul.dll +0x40d550e]
#05: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7b5533]
#06: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7b4d14]
#07: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7b618d]
#08: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0x87ffa63]
#09: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0x8815f6c]
#10: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0x87efdb1]
#11: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7b5285]
#12: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7c818c]
#13: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7b4354]
#14: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7b4e17]
#15: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0xa7b618d]
#16: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0x8bfdd2f]
#17: XRE_GetBootstrap[T:\mozregression\thunderbird\xul.dll +0x8bfe56e]
#18: ??? (???:???)

In case this helps.

When printing PDF with TB 137.0.1 (having started it from a terminal,
not the app menus), I also see errors in terminal output, something like:

[GFX1-]: DrawSurface with bad surface 1
[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0x7f335b6c2700, context 0x7f3365256a00, status 0

Also, curiously, not all printing is fully blank. About to attach two files:
SU-orig.pdf as saved from TB, SU-sent.pdf as TB sent to the CUPS server.

Attached file SU-orig.pdf —
Attached file SU-sent.pdf —

Same problem Thunderbird 137.0.1

Please try Daily (on https://www.thunderbird.net/en-US/thunderbird/all/ select the daily channel).

Lee, does comment 20 warrant some additional fixes? That assert was added in bug 1950596.

Flags: needinfo?(lsalzman)
Duplicate of this bug: 1960559

Can the severity of this be increased, since it affects a release product, and a major function (printing) is now broken?

Flags: needinfo?(mkmelin+mozilla)

Fixes for bug 1959409 and bug 1959815 have both been uplifted to 138.

Flags: needinfo?(lsalzman)

Worcester12345, is the bug summary not accurate - is all printing broken and not just pdf?

Thunderbird 138.0b3 comes in the next few days, which will deliver this fixes and it will be helpful for everyone to test them there.

Printing pdfs works for me now, but it would be good if someone else can also confirm on daily (or 138.0b3 soon).

Flags: needinfo?(mkmelin+mozilla)

Having same bug with 137.0.1 on OSX 14.7.5 Totally blank pages. This was not an issue before the 137.0.1 update.

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

Printing pdfs works for me now, but it would be good if someone else can also confirm on daily (or 138.0b3 soon).

I can still reproduce the issue on Daily 139.0a1 20250416004206 Windows11.

Same problem Thunderbird 137.0.2 ((

I wonder if this extension will help until the developers fix the problem? https://addons.thunderbird.net/en-us/thunderbird/addon/printingtools-ng/

I re-tested this, and indeed it's not fixed after all. It's working for some (simple) pdfs but not other. Errors from comment 4 are still happening.
Lee, any further ideas?

Flags: needinfo?(lsalzman)

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

I re-tested this, and indeed it's not fixed after all. It's working for some (simple) pdfs but not other. Errors from comment 4 are still happening.
Lee, any further ideas?

Is there a way to test this in Firefox proper rather than Thunderbird? It's not easily possible for me to test/develop on Thunderbird at the moment, so I would need a way to reproduce the issue in Firefox to investigate further.

Flags: needinfo?(lsalzman)

Unfortunately I don't know of a way. Is there perhaps some pref that controls behavior around this and we have it different?

The assertion in comment 20 probably explains the issue but no idea how Thunderbird gets here and not Firefox.

Hi, its not fixed completely. It prints PDFs that are text like, but if theres some PDFs with images or an invoice with some graphical art decoration it will print blank in Thunderbird.
Im available to test or debug anything in Thunderbird, just teach me how.
Thanks.

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

Unfortunately I don't know of a way. Is there perhaps some pref that controls behavior around this and we have it different?

The assertion in comment 20 probably explains the issue bug no idea how Thunderbird gets here and not Firefox.

According to comment 20, the problem seemingly is that the canvas created is too large, and failing because of this.

Calixte, did you make any recent change to PDFjs that causes it to create these gigantic unsupported canvases?

Flags: needinfo?(cdenizet)
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED

I just posted a patch to potentially address at least one of the issues in the logs shown to me.

If someone could apply the patch to a Thunderbird build and let me know if it further resolved the issue, that would help.

(In reply to Lee Salzman [:lsalzman] from comment #39)

According to comment 20, the problem seemingly is that the canvas created is too large, and failing because of this.

Calixte, did you make any recent change to PDFjs that causes it to create these gigantic unsupported canvases?

No I didn't.
The canvas we use in order to print is created here:
https://searchfox.org/comm-central/rev/da9f91d5e08cf84932aead6b40cab1f0e0397112/mozilla/toolkit/components/pdfjs/content/web/viewer.mjs#6307-6315

I checked the value we get in Firefox and in TB and they're the same: the width is 1275 and the height is 1650 (the pages dimensions are 612x792).
The Cairo logs show:

[GFX2-]: Allowing surface with invalid size (Cairo) Size(48960,63360)

So it looks like the dimensions are multiplied by 38.4.

Flags: needinfo?(cdenizet)

I just replaced the drawing part of the mozPrintCallback by a single call tofillRect (with a red color) and I still get the warnings about the invalid Cairo surface with the same values, but it isn't crashing anymore and the output pdf has 3 red pages ! so the dimensions are very likely not the problem here.
I'd say that removing the assertion should fix the problem (I'm using an artifact build so I can't test Lee's patch).

I'm from Brazil, and I have the same problem.

Tested the (In reply to Lee Salzman [:lsalzman] from comment #41)
Thanks! The patch seems good to me. At least the 3 pdfs I tried that didn't work before now print ok.

Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f5c9e5195b5c Guard against imbalanced clips in DrawTargetCairo. r=aosmond

Can anyone give me an idea of ​​when this fix will be in the stable Thunderbird release?

The fix is currently landing (should be available in the Daily available in ~4-5h). Probably it could then be uplifted to 138beta with v138 final releasing April 29.

Severity: -- → S2

https://hg.mozilla.org/mozilla-central/rev/f5c9e5195b5c

Status: ASSIGNED → RESOLVED
Closed: 12 days ago
Resolution: --- → FIXED
Target Milestone: --- → 139 Branch

Is this really not going to be fixed until Thunderbird 139.0? This is a fairly major defect.

Status: RESOLVED → VERIFIED

Comment on attachment 9479360 [details]
Bug 1959171 - Guard against imbalanced clips in DrawTargetCairo. r?aosmond

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: Broken PDF printing in Thunderbird.
  • Is this code covered by automated tests?: Unknown
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Converts an assertion to a warning.
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9479360 - Flags: approval-mozilla-beta?

Comment on attachment 9479360 [details]
Bug 1959171 - Guard against imbalanced clips in DrawTargetCairo. r?aosmond

Approved for 138.0b9

Attachment #9479360 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: