1896994 - messenger.messages.getAttachmentFile() method stalling while retrieving linked attachments

Status: RESOLVED DUPLICATE of bug 1896773

(Thunderbird :: Add-Ons: Extensions API, defect, P2)

Description

[tmccoid]

Attachment: getAttachmentFile-stall.eml

Steps to reproduce:

Called messenger.messages.getAttachmentFile against a "linked" (remotely-stored) attachment

A sample .eml file is included with this report to assist in troubleshooting. The "linked attachment" in the file can reproduce the issue when used against the Extract 'Em! extension, or possibly if two consecutive attempts are made to retrieve the file via getAttachmentFile()

Actual results:

Intermittently, the call stalls indefinitely.

For background, my extension Extract 'Em! batch extracts attachments. There are two phases: discovery (identifying attachments) and packaging (retrieving the files and adding them to the result archive/.zip file). In cases where the size of the attachment (as presented in the MessageAttachment object obtained during discovery) is zero, the extension will fetch the file via getAttachmentFile solely to obtain the size.

A user reported the extension stalling intermittently; I have tracked this down to the call to getAttachment file in the case where the attachment is not embedded in the email message but linked via the X-Mozilla-External-Attachment-URL header in the attachment part. This is not occurring in a perfectly deterministic fashion according to the user who reported the issue; however, since these types of attachments (at least in the small sample set I have tested against) have a size of zero, the file is actually downloaded twice -- once during discovery and once during packaging -- and during the former it seems to complete without issue, but stalls during the latter.

Interestingly, although the method does not return (at least not in a timely fashion) in that latter case, viewing the Network monitor demonstrates that the file was successfully retrieved on both occasions.

Expected results:

The call to the method should reliably return once the file is successfully downloaded, or throw an error if problems are encountered.

Comment 1

[tmccoid]

Attachment: getAttachmentFile-stall.png

Screenshot demonstrating successful download of "linked" attachment file

Comment 2

[Magnus Melin [:mkmelin]]

xref/dupe bug 1896773

Comment 3

[John Bieling]

The API should not download attachments. So once we add a special "remote" / "link" property to the API, getAttachmentFile() should probably no longer retrieve such attachments. For the API, they should be handled identically to cloudFile attachments.

Comment 4

[John Bieling]

To sum up the current situation:

• This was filed against Thunderbird 115, but in Thunderbird 128 this no longer happens, because the call to getAttachmentFile() returns the placeholder text (This MIME attachment is stored separately from the message.) instead of trying to download the remote file.
• You are able to identify these attachments by looking at the X-Mozilla-External-Attachment-URL header and fetch the attachment from there. fetch() may run into CORS, in which case you need to request the <all_urls> permission to get around that. But a service which hosts remote attachments should not cause CORS, except the message was generated by an RSS reader which links images from the webpage :-)
• You would like to have the url directly in the attachment info
• This is what we want to do in bug 1896773