[Thunderbird] Access to messages headers

[Benoît Bailleux]

Hello,

I'm trying to create a simple add-on that adds a column with just an
icon for some messages (if they contains an invitation to a meeting).
But maybe am I blind (or stupid), but I can't find a way to read header
field that I'd like. It seems that only some of them are available
through the "getMsgHdrAt" method.
Ideally, I'd like to
1. read the headers and see if the Content-Type is "multipart"
2. if yes, access the list of parts
3. if one of them is "Content-Type: text/calendar" --> add the right icon

Can someone points me to a resource that might help me ?
Thanks in advance.

Regards,
--
Benoīt Bailleux

[Neil]

The only way to read the content type of attachments is to stream the
message, which isn't done by default. In particular, it's a slow
operation, so you can't do it from your custom column handler.

The lazy way is to watch messages as they are loaded into the message
pane, because you can then look at the list of attachments and see if
any of them have the content type you're interested in and if so set a
property on the header that your custom column handler reads. (As I
recall, this is how the attachment icon itself works.)

The eager way is to watch for new messages and force them to be streamed
in the background to your listener which can then listen out for an
appropriate attachment. Fortunately there is a function to do all the
heavy lifting for you:

http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/mimemsg.js#146

--
Warning: May contain traces of nuts.

[alta88[nntp]]

there is an extension, not (yet) on AMO, that does this generically for
attachments. so if you have application/ics (typical Lightning invite
content) handler defined in Tb attachment content types, it should
display that icon.

http://attachmentcount.mozdev.org/

note that if you want to do this specifically for text/calendar within a
multipart/alternative envelope (a typical Lightning invite), you will
have to stream the mime message for each mail and parse the parts. if,
instead, the icon for the attachment type is fine (and there is one),
then AttachmentCount might suffice. it only processes those messages
that already have an attachment flag emitted.

i have found some issues with MsgHdrToMimeMessage(); it fails for nntp
messages and it seems to have regressed on current trunk.

[Jonathan Protzenko]

> i have found some issues with MsgHdrToMimeMessage(); it fails for nntp
> messages and it seems to have regressed on current trunk.

It is definitely known that the function doesn't work for NNTP
messages, but I'd be happy to hear your thoughts as to how the function
regressed on trunk :).

jonathan

[alta88[nntp]]

This is html.

[Benoît Bailleux]

Le 29/01/2013 18:25, alta88[nntp] a écrit :
> [...]

> there is an extension, not (yet) on AMO, that does this generically for
> attachments.

Very nice extension.
Just a small annoyance (TB 17.0.2, Linux Ubuntu 12.04.1) with the
preview feature: when I click on the icon of an eligible attachment, the
preview is displayed, and then the same content is still displayed when
hovering on any other message as well. Until I click again on any other
message. This happens only on message with an "Object" string short
enough to fit in the message pane.

> [...]

>
> note that if you want to do this specifically for text/calendar within a
> multipart/alternative envelope (a typical Lightning invite), you will
> have to stream the mime message for each mail and parse the parts.

That seems to be exactly what I need. Are the parts included in such a
message type accessible with a specific method? A first and quick trial
with "MimeMessage.allAttachments" gave me an empty list of parts.
Isn't "stream[ing] the mime message for each mail and parse the parts"
what AC is actually doing?

> if, instead, the icon for the attachment type is fine (and there is one),
> then AttachmentCount might suffice. it only processes those messages
> that already have an attachment flag emitted.

As I don't know how messages are build and processed, I don't understand
that. Do you mean that the messages of type "multipart/alternative"
should already have a specific icon displayed by AC? Is there a specific
header for messages with attachment? I suppose that messages of type
"multipart/alternative" don't have that flag, right?

> [...]

Do you think that AC can be extended to display an icon whenever a
message is actually a calendar invite? My main concern is actually that
99.9% of my colleagues use Outlook, and sometimes their invite stay
unread in my inbox because nothing has catched my eyes.

Regards,
--
Benoît Bailleux

[alta88[nntp]]

---On 2013.Jan.31 5:44 AM, Benoît Bailleux wrote:
> Le 29/01/2013 18:25, alta88[nntp] a écrit :
>> [...]
>> there is an extension, not (yet) on AMO, that does this generically for
>> attachments.
>
> Very nice extension.
> Just a small annoyance (TB 17.0.2, Linux Ubuntu 12.04.1) with the
> preview feature: when I click on the icon of an eligible attachment, the
> preview is displayed, and then the same content is still displayed when
> hovering on any other message as well. Until I click again on any other
> message. This happens only on message with an "Object" string short
> enough to fit in the message pane.
>

yes, a second click is necessary to collapse it. it is unknown when the
user wants it collapsed, perhaps it should auto collapse if cursor is
moved off the row. this is just an experiment anyway.

>> [...]
>>
>> note that if you want to do this specifically for text/calendar within a
>> multipart/alternative envelope (a typical Lightning invite), you will
>> have to stream the mime message for each mail and parse the parts.
>
> That seems to be exactly what I need. Are the parts included in such a
> message type accessible with a specific method? A first and quick trial
> with "MimeMessage.allAttachments" gave me an empty list of parts.
> Isn't "stream[ing] the mime message for each mail and parse the parts"
> what AC is actually doing?
>

because the parser doesn't think the text/calendar part is an
attachment, and technically it isn't. so you have to
get back the result (the entire mimemsg) and parse it manually. a
lightning invite, for example, is sent as a true attachment, with an
application/ics content type and file extension .ics. if this were the
only attachment, then AC would show the icon for whatever your handler
is for that type.

>> if, instead, the icon for the attachment type is fine (and there is one),
>> then AttachmentCount might suffice. it only processes those messages
>> that already have an attachment flag emitted.
>
> As I don't know how messages are build and processed, I don't understand
> that. Do you mean that the messages of type "multipart/alternative"
> should already have a specific icon displayed by AC? Is there a specific
> header for messages with attachment? I suppose that messages of type
> "multipart/alternative" don't have that flag, right?
>

no, since within that envelope it's not a content-disposition of
attachment. if Tb thinks a message might have an attachment, the
headers will have a flag (it is adjusted later on message open). if you
set View->Message Body As->All body parts, a flag will always be emitted
(this option may be hidden, there's an ext to unhide it, i forget the
latest status). but then, even the content is a mime part.

>> [...]
>
> Do you think that AC can be extended to display an icon whenever a
> message is actually a calendar invite? My main concern is actually that
> 99.9% of my colleagues use Outlook, and sometimes their invite stay
> unread in my inbox because nothing has catched my eyes.
>

well, it could but. 'actually a calendar invite' has to be strictly
defined. if it isn't an attachment, it would be strictly incorrect to
show it as such. another real attachments would override the icon. and
more than one attachment always shows a count. so it would be a rather
significant semantic exception.

perhaps a specific calendar invite column is better. i suppose it could
be added to AC. it would be nice if MsgHdrToMimeMessage() were more robust.

> Regards,