1721577 - Enrich nsIMsgHdr to include reply-to, so it can be used in MessageHeader directly

Status: RESOLVED DUPLICATE of bug 1777169

(Thunderbird :: Add-Ons: Extensions API, task)

Description

[Int]

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

Steps to reproduce:

I want to read the Reply-To field of a mail from a MailExtension Addon but the API type MessageHeader
https://webextension-api.thunderbird.net/en/latest/messages.html#messageheader
does not include the Reply-To field.

Actual results:

Reply-To field not available in MessageHeader

Expected results:

MessageHeader should also include the Reply-To field of a mail as it does for recipients, ccList, bccList and author.

Comment 1

[John Bieling]

Can you check, if the MessagePart includes it with all the other headers?
https://webextension-api.thunderbird.net/en/latest/messages.html#messagepart

Comment 2

[Int]

Yes, messagepart.headers["reply-to"] does contain the correct reply-to address.

But I think this should be available through MessageHeader without having to load the full email with messenger.messages.getFull().

Comment 3

[John Bieling]

The information provided in the MessageHeader is taken directly from the nsIMsgHdr object, which does not include the reply-to information.

We return a MessageHeader in multiple places and sometimes in greater number (lists). If we need to actually read every message, to manually populate the reply-to header of the MessageHeader, this would cause a huge performance break down. So at the moment and in the near future, this will not change.

In order to get this included, the core implementation of the nsIMsgHdr and the database needs to be changed, both being a lot more work than what I think the gain is worth.

So let us either move this to the core component (and let them add the reply-to header), or close it as wontfix.

Comment 4

[Int]

OK, I can live with reading the messagepart.headers["reply-to"] if it's such a big deal to implement in MessageHeader.
But of course I can only speak for myself.

It's up to you how you want to handle this.

Comment 5

[John Bieling]

I will close this bug in favour of Bug 1777169, where I collect requests for additional headers.