Closed Bug 1550960 Opened 3 years ago Closed 8 months ago

Access Attachment List from Thunderbird extension using WebExtension API

Categories

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

enhancement

Tracking

(thunderbird_esr78 wontfix)

RESOLVED FIXED
88 Branch
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: davidebagnato97, Assigned: darktrojan)

References

Details

Attachments

(1 file)

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.

Summary: Access Attachment List from Thunderbird extension using WebExtension → Access Attachment List from Thunderbird extension using WebExtension API
Flags: needinfo?(geoff)

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.

Blocks: webext-tb
Status: UNCONFIRMED → NEW
Type: defect → enhancement
Ever confirmed: true
Flags: needinfo?(geoff)

(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.

Depends on: 1575708
Priority: -- → P2

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"

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?

Flags: needinfo?(davidebagnato97)

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

(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.

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

Assignee: nobody → geoff
Status: NEW → ASSIGNED
Depends on: 1696863
Attachment #9207347 - Attachment description: Bug 1550960 - Message attachments API → Bug 1550960 - Message attachments API. r?john.bieling

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.

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?

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

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.

(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.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/5e895eb7cecd
Message attachments API. r=john.bieling

Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch

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

Duplicate of this bug: 1623685
Duplicate of this bug: 1606552
Depends on: 1698270
Flags: needinfo?(davidebagnato97)
You need to log in before you can comment on or make changes to this bug.