User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 Edg/111.0.1660.14

Steps to reproduce:

Some messages are missing the header when opened. The header is however present in the message listing and Print Preview.

Is this some particular email? If so, can you attach a sample as .eml?

Attached is the message.

Could it be caused by some add-on? Try Help | Troubleshoot mode.
Other idea would be to use Repair Folder in the folder properties.

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

Could it be caused by some add-on? Try Help | Troubleshoot mode.
Other idea would be to use Repair Folder in the folder properties.

Sorry, it does not work with either option. Since the anomaly has only been observed in 1 email, I suppose I can ignore this.

It displays fine for me when using 111.0b3 in standalone message window.

This is random. I have just observed a second message today. This is not coming from the same sender or domain.

Do you see this when using version 113?

I currently run 112 beta 7. I didn't know 113 is available?

testcase attachment 9321425 [details] wfm on Beta 113.0b3 (64-bit), Win10, all headers correctly displayed in message preview or msg tab.

Reporter, does an affected message like attachment 9321425 [details] sometimes display correctly, or it displays wrong every time?

Update: 113b3:
Cannot preview message contents in some messages. The same is OK when accessed from a different client.

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

Reporter, does an affected message like attachment 9321425 [details] sometimes display correctly, or it displays wrong every time?

Reporter, can you please answer this question?

(In reply to pmuiruri from comment #5)

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

Could it be caused by some add-on? Try Help | Troubleshoot mode.
Sorry, it does not work with either option. Since the anomaly has only been observed in 1 email, I suppose I can ignore this.

Are you sure that you have restarted Thunderbird in troubleshoot mode?

This may or may not be supernova 3pane related, and so far we cannot reproduce.

thunderbird -safe-mode makes no difference.

Probably similar to bug 1821988

I'm experiencing this suddenly with the same receiver.
Header and attachment bar are empty, but the body is there. If I print the message or view source everything is there.
No errors in the console.
I'll see if I can figure out what's going on.

I noticed this console error when trying to view the affected messages:
JavaScript error: resource://devtools/server/actors/webconsole/listeners/document-events.js, line 118: TypeError: can't access property "timing", window.performance is null
Does this ring any bell?

Just encountered this too, some observations:

• The message had an attachment when I viewed the source, but the attachment flag wasn't set (no paper clip icon)
• Repairing the folder it was in fixed the issue temporarily
• I also saw that error when the message was being viewed, not sure that's related to the issue though.

This was broken by https://hg.mozilla.org/comm-central/rev/8689605fa4c8901006b16e50aaa5e4d9bf6ce700 - bug 1799764

AFAICT it only affects IMAP messages which have an offline copy of the message. I have a message I can reproduce with, and that works fine when moved to a local folder.
Looks like order of events are slightly different for the problem case. But I don't fully understand why the message in question triggers this behavior. It's 2.3MB, but I can't reproduce even with larger messages.

(In reply to Alessandro Castellani [:aleca] from comment #19)

I noticed this console error when trying to view the affected messages:
JavaScript error: resource://devtools/server/actors/webconsole/listeners/document-events.js, line 118: TypeError: can't access property "timing", window.performance is null

Curiously this always happens with this particular mail. But seems harmless.

Gene, while looking into Magnus's patch, I worked out that the problem is caused here. I think this removal from the load group makes the progress listener event happen too early. Later on, logging from the load group complains about the channel already being removed, so I think we're actually doing it twice (presumably in nsImapMockChannel::Close). Removing those three highlighted lines from OnStopRequest fixes this bug and none of the tests complain, do you think it's a reasonable thing to do?

Testing with those 3 lines removed with no offline store and huge messages (45 to 100Mb) each with several attachments, I'm seeing problems. The message header (seen in preview) doesn't agree with the message content and sometimes I don't see the attachment list at the bottom. Don't see these problems with the 3 lines back in.

I'll look closer and see if something else I changed might be causing this related to the disk cache change. It does look like the Close() remove load group could occur twice the way it currently is and cause this bug.

Reading comments above, it sounds like it's random. Does anyone have a sample .eml that always causes the reported bug?

I tried the reporter's example email attached above and with it I usually see, but not always, blank fields in the preview header area. The message body and attachment seem OK (Edit: Actually, I've seen the pdf attachment link at the bottom not present, so only see the message body.). Then if I move to another email and back to that one I then sometimes see all the fields and sometimes not. This is with a folder with offline store (mbox). I also put the email in a imap folder without offline store and see the same thing.

The problem access is coming directly from either offline store or from disk cache. If I clear cache and read the message from imap, the first time it shows the header OK.

Removing the 3 lines pointed to by https://searchfox.org/comm-central/rev/fc296ef9528551f5baa1040a58366dad91823ff1/mailnews/imap/src/nsImapProtocol.cpp#8763-8765 didn't make a difference (other than breaking access to my largest messages as described in comment 26). I also tried adding a parameter to Close() so that if removal of load group has already occurred in OnStopRequest() it is not done again in Close(), but that didn't help either.

Finally I applied the mkmelin patch and that fixed it (now always see the proper header fields and link to pdf attachment in the preview pane for the test message).

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/10277c245186
Ensure request is finished before trying to use data from the mailchannel. r=darktrojan

Comment on attachment 9338222 [details]
Bug 1819916 - Ensure request is finished before trying to use data from the mailchannel. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): bug 1799764
User impact if declined: sometimes message headers are not shown at all, and/or attachments do not appear
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): not risk free. Needs to go with bug 1840087

Comment on attachment 9338222 [details]
Bug 1819916 - Ensure request is finished before trying to use data from the mailchannel. r=darktrojan

[Triage Comment]
Approved for beta

Thunderbird 115.0b6:
https://hg.mozilla.org/releases/comm-beta/rev/0ed4166f6796