1550960 - Access Attachment List from Thunderbird extension using WebExtension API

Status: RESOLVED FIXED

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

Description

[Davide Bagnato]

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

Steps to reproduce:

I tried to inject a content script to get the Attachment list and other elements with the new WebExtension API (without XUL overlay) but it doesn't work in the main Thunderbird tab because is somehow protected from injection.
I searched another way but apparently there isn't. How can i get those items using the new API?

Expected results:

The attachment list should have appeared in the popup of the extension through a content script and a message passing.
It seems there isn't a way to access those items from the popup.

Comment 1

[Geoff Lankow (:darktrojan)]

That's not currently possible, but you can get access to the attachments with the messages.getFull method. I realise it's not quite what you want.

Comment 2

[Davide Bagnato]

(In reply to Geoff Lankow (:darktrojan) from comment #1)

That's not currently possible, but you can get access to the attachments with the messages.getFull method. I realise it's not quite what you want.

Thank you for the answer, i'll try soon to access them in the MessagePart through that method.

Comment 3

[Anthony]

getFull method gives a access to array of MessagePart, but for example: MessagePart with contentType equal "image/jpeg" has not property body o any other handle to get data from this part instead of contentType equal to "text.plain"

Comment 4

[Mark Banner (:standard8)]

Davide, it is unclear to me what you wanted to be able to do originally in this bug. Did you want just a list of attachments, or the actual contents, or something else?

Comment 5

[Anthony]

Need a method to access attachment body. For example to save it on local disk.

Comment 6

[Mark Banner (:standard8)]

(In reply to Anthony from comment #5)

Need a method to access attachment body. For example to save it on local disk.

That could be provided by bug 1696777 where the add-on wouldn't need access to the body. Alternately, bug 1606552 could provide a way to get the attachment body. We probably do want both.

I am specifically asking the original reporter to try and understand what the intent of this bug is - to me it is unclear. It is possible that we could close this as a duplicate of one of those two, or perhaps we need to expand on what is needed here.

Comment 7

[Geoff Lankow (:darktrojan)]

I have an incomplete patch for this that I haven't touched for months and had forgotten about.

Comment 8

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1550960 - Message attachments API. r?john.bieling

Comment 9

[Mark Banner (:standard8)]

I have a concern about this API. In particular that it is not linked to messages.getFull() - so you can get detail about the structure of the message from getFull, but not the attachments themselves.

The reason this is potentially important is for when messages are forwarded inline. At the moment the listAttachments API defined here will return an array of the attachments included in both the main message and the one that has been forwarded inline. The add-on would have no way to determine which belonged to which without doing manual correlation with the results of getFull().

Calling getFull() you get the message.rfc822 as a part, with the attachments on that inline message as sub-parts, so you can easily determine where they belong to.

I do like the idea of having a separate listAttachments as it makes getting the list easy when you aren't worried about the message structure itself, but I'm thinking maybe the getFile part should be incorporated into getFull, as that will help to get add-on authors to think about if the structure is relevant or not?

I know this is an old patch that has just been posted, but it'd also be nice to get these types of proposals/additions mentioned on topicbox so that we can check they fulfil author's needs.

Comment 10

[John Bieling (:TbSync)]

Geoff, since we just discussed to return IDs instead of a getFile function, can we include those IDs in getFull as well?

Standard8, would that solve your requirement? So whenever getFull returns a part which is an attachment, it includes an ID, which than can be used to retrieve the actuall attachment by a getAttachment(id) method?

Comment 11

[Geoff Lankow (:darktrojan)]

Yes, I think actually it would be a good idea to identify attachments by message id and part id.

Comment 12

[Mark Banner (:standard8)]

One way to do it might be to use the part name rather than the ID - so you'd need a message id plus attachment id. I'm not 100% sure though if the part names are guaranteed unique as I don't know exactly where they come from.

I think it will still be a little strange having a getFull function where you can't actually get the full details of the message from, but maybe that's ok.

Comment 13

[Geoff Lankow (:darktrojan)]

(In reply to Mark Banner (:standard8) from comment #12)

One way to do it might be to use the part name rather than the ID - so you'd need a message id plus attachment id. I'm not 100% sure though if the part names are guaranteed unique as I don't know exactly where they come from.

I think it will still be a little strange having a getFull function where you can't actually get the full details of the message from, but maybe that's ok.

I've just updated the patch, and it basically now does what you propose. The identifier is now the same as returned by getFull, which AIUI is just a counter for each multipart/* level so it has to be unique.

I was kinda already heading in this direction after John and I discussed abandoning the child-side getFile function on Attachment objects, which we should do because it wasn't the smartest idea.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/5e895eb7cecd
Message attachments API. r=john.bieling

Comment 15

[max]

It seems, one line touched in the course of work on this bug fixed the Bug #1623685 (messages.getFull for IMAP) as well.