(In reply to Jim Porter (:squib) from comment #25)
> (In reply to Jim Porter (:squib) from comment #24)
> > As an alternative, we could add a displayableInline property to nsMsgAttachmentData
> > and show all non-displayable-inline parts in the attachment list.
>
> Hmm, maybe we should do this, since apparently some MUAs actually send
> attachments as multipart/alternative subparts: bug 636253.
This actually works with the current patch.
One limitation, however, is that text/whatever parts will get shown inline after the "proper" body (so you'd have, e.g. text/html and text/whatever shown inline). This is because we try to find a handler for the *exact* MIME type when determining if we're at the last inlinable part, but then when we try to show it, we fudge things, and treat unknown text/* parts as text/plain. Maybe we should add an option to mime_create that forwards exact_match_p onto mime_find_class? This would also let me remove the "text/calendar" handling in mime_find_class. Ideas?
(In reply to Jim Porter (:squib) from comment #25) -inline parts in the attachment list. alternative subparts: bug 636253.
> (In reply to Jim Porter (:squib) from comment #24)
> > As an alternative, we could add a displayableInline property to nsMsgAttachmentData
> > and show all non-displayable
>
> Hmm, maybe we should do this, since apparently some MUAs actually send
> attachments as multipart/
This actually works with the current patch.
One limitation, however, is that text/whatever parts will get shown inline after the "proper" body (so you'd have, e.g. text/html and text/whatever shown inline). This is because we try to find a handler for the *exact* MIME type when determining if we're at the last inlinable part, but then when we try to show it, we fudge things, and treat unknown text/* parts as text/plain. Maybe we should add an option to mime_create that forwards exact_match_p onto mime_find_class? This would also let me remove the "text/calendar" handling in mime_find_class. Ideas?