Last Comment Bug 235629 - thunderbird does not show xhtml attachments inline
: thunderbird does not show xhtml attachments inline
Status: NEW
: helpwanted
Product: Thunderbird
Classification: Client Software
Component: Mail Window Front End (show other bugs)
: unspecified
: x86 Linux
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-25 14:47 PST by Darin Fisher
Modified: 2010-04-18 05:16 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch to show application/xhtml as inline content (633 bytes, patch)
2004-03-02 20:24 PST, Scott MacGregor
no flags Details | Diff | Review

Description Darin Fisher 2004-02-25 14:47:28 PST
Thunderbird does not show xhtml attachments inline.

I'm using the Linux Thunderbird 0.5 (20040208) build.

It seems like Thunderbird should be able to render xhtml attachments inline.
Comment 1 Scott MacGregor 2004-02-25 23:16:30 PST
i'm not sure where we decide if a part is inline or not. it's probably in
libmime hard coded as text/* and image/* or something along those lines....

what's the content type for xhtml files?
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-02-26 00:38:25 PST
application/xhtml+xml
Comment 3 Christian :Biesinger (don't email me, ping me on IRC) 2004-02-26 05:13:10 PST
application/xml would be a valid content type as well, I think... as well as
text/xml.
Comment 4 Scott MacGregor 2004-03-02 20:24:09 PST
Created attachment 142807 [details] [diff] [review]
patch to show application/xhtml as inline content
Comment 5 Scott MacGregor 2004-04-16 16:57:27 PDT
this stuff can go into the 1.8 trunk
Comment 6 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-16 17:32:51 PDT
Might it be worth following the pref stored in the html_as variable?
Comment 7 Scott MacGregor 2004-07-12 18:08:29 PDT
not a .8 stopper. I may not have time to bounce back to this before 1.0
Comment 8 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-26 20:47:32 PDT
Maybe this should use nsIWebNavigationInfo (see bug 283125) so that this code
doesn't have to be updated every time we add support for a new MIME type?  (That
said, it does need to restrict things a bit, e.g., not using plugins.)
Comment 9 Christian Schmidt 2008-01-08 15:50:30 PST
Some findings:
Changing mailnews/mime/mimei.cpp is not enough. "text/html" and TEXT_HTML are treated specially in several places in mailnews/mime/*.

A MIME part whose Content-Type is not one of the currently supported ("text/html", "multipart/*" etc.) shows up as an attachment. 

application/xhtml+xml is currently parsed as HTML tag soup rather than XML.
Comment 10 Frédéric Wang (:fredw) 2010-04-18 05:16:32 PDT
(In reply to comment #9)
> Some findings:
> Changing mailnews/mime/mimei.cpp is not enough. "text/html" and TEXT_HTML are
> treated specially in several places in mailnews/mime/*.
> 
> A MIME part whose Content-Type is not one of the currently supported
> ("text/html", "multipart/*" etc.) shows up as an attachment. 
> 
> application/xhtml+xml is currently parsed as HTML tag soup rather than XML.

Yes, changing mailnews/mime/mimei.cpp makes application/xhtml+xml attachments display inline but they are still loaded with the HTML parser.
I'm just wondering... isn't libmime simply splitting the different parts of a message? So we need to indicate elsewhere in mail/ or mailnews/ that the file has to be loaded as application/xhtml+xml?

Note You need to log in before you can comment on or make changes to this bug.