Bug: Sometimes see duplicate attachments listed when opening huge emails with attachments.
Status: NEW
Priority: --
Created: 2023-12-15 02:35:52+00:00
Resolved: 2023-12-24 00:34:41+00:00

Paraphrasing from bug 1869226 comment 4:

~~I am seeing a problem with big PDFs in tabs not coming back after a restart. I'm not seeing anything about "imap not registered" (bug1846054)  and the fix for that bug had no effect on this bug. What I see is that, after restart, for some tabs the loading progress indicator at the top gets about 1/3 of the way and just stops and the tab for showing the PDF remains empty. I had 3 tabs with the large PDF open with 2 blank and one showing after restart of daily. Then I shut down newest daily and started old 110. Daily 110 (pre-SN) was the last version I tested this extensively with and had it was working fine. When I started 110, all the tabs loaded as they should. I also added more PDF tabs with 110 and shutdown and restarted and they all came back fine. (These are huge 30M PDF in each tab.) Since I haven't made any changes in imap or disk caching code that handles this since 110, it must be the the other UI related changes affecting this.~~

With new daily (and I assume also 115) initial loading the huge messages from cache is more sluggish but is still reliable [with inline attachments, see below] until after a restart when re-loading tabs has problems.

Another thing I see with latest daily is that on open some of my huge test messages (about 100M) for testing disk caching sometimes show duplicate attachment links for the same message, e.g., there are only 5 attachments but 10 are actually listed and most shown twice. This seems to only occur for attachments that can't be shown inline like PDFs. This occurs for messages in folders with and without offline mbox store, so doesn't seem related to disk caching.
I just noticed that duplicates are NOT shown when I turn off "Display Attachments Inline". ~~However, when I do this, a PDF never appears in a tab at all, not just after a restart.~~ (Edit: They are now appearing OK.)
When PDF don't appear in tabs I see errors like this on console:
```
[Parent 1119571, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A (NS_ERROR_MALFORMED_URI): file /home/gene/mozilla2/comm/mailnews/base/src/nsMsgMailNewsUrl.cpp:503
[Parent 1119571, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x804B000A (NS_ERROR_MALFORMED_URI): file /home/gene/mozilla2/comm/mailnews/imap/src/nsImapService.cpp:2257
[Parent 1119571, Main Thread] WARNING: NS_ENSURE_TRUE(*aServer) failed: file /home/gene/mozilla2/comm/mailnews/imap/src/nsImapService.cpp:2230
[Parent 1119571, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /home/gene/mozilla2/comm/mailnews/imap/src/nsImapService.cpp:2270
[Parent 1119571, Main Thread] WARNING: NS_ENSURE_TRUE(*aServer) failed: file /home/gene/mozilla2/comm/mailnews/imap/src/nsImapService.cpp:2230
```
So something malformed about a URI. But the URI that appears in the PDF tab looks about the same whether it displays or not:
```
works:
imap://gene@wally.dbnet.lan:993/fetch%3EUID%3E.555%3E228?part=1.3&filename=codpaste-teachingpack.pdf&type=application/pdf
bad:
imap://gene@wally.dbnet.lan:993/fetch%3EUID%3E.555%3E229?part=1.5&filename=codpaste-teachingpack.pdf&type=application/pdf
```
The only difference here is that the one that works if from message UID 228 and the one that is bad is from message UID 229 and they have different "part" numbers in the mime structure.

Edit: The MALFORMED_URI messages above are still occurring even now that the PDFs are displaying OK.