638325 - TB doesn't read it's own multipart text/plain even when Veiw>Body As>Plaintext is set.

Status: RESOLVED DUPLICATE of bug 253830

(Thunderbird :: Message Reader UI, defect)

Description

[dline8es]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15pre) Gecko/20110214 Ubuntu/8.04 (hardy) Namoroka/3.6.15pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15pre) Gecko/20110207 Shredder/3.1.9pre

TB is downconverting the multipart text/html instead of displaying text/plain.
This is when View>Message Body As>Plaintext is set.

I also checked the settings described in:
http://www.bucksch.org/1/projects/mozilla/108153/
and 
mailnews.display.prefer_plaintext=true
html_as=1
disallow_mime_handlers=1


Reproducible: Always

Steps to Reproduce:
1. Create an html email with an embedded image.
2. Specify Options>Format>Plain and Rich Text
2. Send it to yourself
4. Edit the message before opening it and add some differentiating txt to the multipart text/html section 
Alternately save the email as an .eml file, and make the changes to that.
5. Set View>Message Body As>Plaintext and open the email (or .eml file)

Actual Results:  
The downconverted multipart text/html section is displayed

Expected Results:  
The plaintext (identifiable because you modified it manually) should be displayed.

I found this problem when using TB to test if my separatly authored multipart email was correct. The plaintext was deliberately much more simple than the html. However TB kept showing plaintext that was obviously downconverted.
I first assumed I was constructing my multipart email incorrectly as it seemed unlikely that TB was messing up.

After much frustration trying to get my plaintext to display I devised this test to see if TB actually display it's own plaintext. If it did, I was going to copy it's multipart construction. But it doesn't! You can only tell if the plaintext and html significantly differ, which won't normally be the case if TB sends a multipart to itself.

I'm using Shredder/3.1.9pre because that's the latest version I could find packaged for Ubuntu 8.0.4

I'll try to attach an "anonymized" .eml after I post this for your own quick testing.

Comment 1

[dline8es]

Attachment: plaintext has an extra text line that doesn't get displayed in affected TB versions

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> 4. Edit the message before opening it and add some differentiating txt to the
> multipart text/html section 

Did you edit mail folder file(Unix mbox format file)? If yes, did you execute Folder Properties/General/Repair Folder? Tb probably automatically executes rebuild-index internally, but do it explicitly if you intentionally change mail data for testing. 

> Alternately save the email as an .eml file, and make the changes to that.
> 5. Set View>Message Body As>Plaintext and open the email (or .eml file)

If test with .eml file, import it by next, please, because directl viewing of .eml file can produce unwanted problems in testing, for ease of problem analysis.
   Drag&Drop .eml file to thread pane. (new feature from Tb 3)

Does View/Message Source show text/plain part data modified by you?
If yes, it's perhaps known issue.
   If multipart/alternative, View>Message Body As>Plain Text, reply in text
   mode, uses down converted text from text/html part.
Please note that it's never RFC violation by Tb, because multipart/alternative is for multiple versions(font/color etc. can be different, text can be replaced by image, ...) of single/same content.
Note: I believe Tb should respect HTML->text conversion by mail sender.

Comment 3

[dline8es]

(In reply to comment #2)
Note: I've narrowed the bug's manifestation conditions. I'll add in separate comment.

> (In reply to comment #0)
> > 4. Edit the message before opening it and add some differentiating txt to the
> > multipart text/html section 
> 
> Did you edit mail folder file(Unix mbox format file)? If yes, did you execute
> Folder Properties/General/Repair Folder? Tb probably automatically executes
> rebuild-index internally, but do it explicitly if you intentionally change mail
> data for testing. 

No it was Maildir accessed by imap. Plus I closed TB (except the test mesg) so that it didn't cache the received version before I made my edit. Doing it this way was just a quick test. The problem originally manifested when I manually author my own multipart/alternative where the text/plain was significantly different. The displayed email was obviously the downconverted html.

The submitted test is what I used to determine if the problem was my multipart/alternative construction or TB's text only rendering.

> > Alternately save the email as an .eml file, and make the changes to that.
> > 5. Set View>Message Body As>Plaintext and open the email (or .eml file)
> 
> If test with .eml file, import it by next, please, because directl viewing of
> .eml file can produce unwanted problems in testing, for ease of problem
> analysis.
>    Drag&Drop .eml file to thread pane. (new feature from Tb 3)

I don't understand. Drag&Drop the file on my hardrive to the bugzilla 'do-not-reply' email in the mesg pane? Sorry, but you'll have to give me a step-by-step on that one...

> Does View/Message Source show text/plain part data modified by you?
> If yes, it's perhaps known issue.
>    If multipart/alternative, View>Message Body As>Plain Text, reply in text
>    mode, uses down converted text from text/html part.
> Please note that it's never RFC violation by Tb, because multipart/alternative
> is for multiple versions(font/color etc. can be different, text can be replaced
> by image, ...) of single/same content.
> Note: I believe Tb should respect HTML->text conversion by mail sender.

I started with a new mesg to avoid these issues.

Comment 4

[dline8es]

Update: Should be called
"TB doesn't display text/plain when email has an alternate text/html section nested in a multipart/related"

I realized the problem 
*only manifests when the text/html references an embedded image!* 

In this case (as stated originally) TB seems to disregard it's own text/plain (generated on send) and display the downconverted text/html (generated on receive)

When I send a similar test email (w/ embedded images) from Evolution, TB properly shows the text/plain (again, I changed text/plain section before running TB)

The difference is the properly displayed email (from Evo) uses a different multipart nesting structure. It is roughly:
Content-Type: multipart/alternative;
->Content-Type: text/plain
->Content-Type: text/html;
->Content-Type: image/jpeg;

The TB generated email which doesn't display properly uses this structure:
Content-Type: multipart/alternative;
->Content-Type: text/plain
->Content-Type: multipart/related;
---->Content-Type: text/html;
---->Content-Type: image/jpeg

As far as I know, The way TB nests the html and embedded images in a multipart/related is correct. Unfortunately it seems to prevent the text/plain section from being presented when requested.

In further testing, when the image section is removed from multipart/related section (so that text/html is the only part nested in multipart/related) the bug is still present.

So we can further reduce the problem statement to:
"text/html nested inside a multipart/related is ALWAYS preferred to text/plain, even when View>Message Body As>Plaintext is enabled.

The originating mailer or the presence of an image doesn't seem to matter.

My guess is this is a fairly simple missed case regarding 'related' sections in the select logic for which version to display.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Same problem as one reported to Bug 253830, isn't it?
(See dependency tree for Bug 505172, please)
> Bug 253830 "View as plain text" displays HTML part converted to plaintext
> even though text/plain part is present
> ( multipart/alternative[ text/plain + multipart/related[ text/html + image/jpeg ] ] )  

For "HTML mail without image" case : Are you looking phenomenon of next bugs?
> Bug 414299 Messages composed with html email composer get sent as plain text
> Bug 136502 Provide prefs. setting to turn off Options -> Format -> Auto-Detect     

For unwanted problems I mentioned if tested with .eml file.
See dependency tree for Bug 269826, please.

(In reply to comment #3)
> No it was Maildir accessed by imap. Plus I closed TB (except the test mesg) (snip)

I see. There is no need to rule out possible unwanted problems in your testing any more, because there is no unwanted problem in your testing.

(Off-Topic)

> >    Drag&Drop .eml file to thread pane. (new feature from Tb 3)
> I don't understand. Drag&Drop the file on my hardrive to the bugzilla
> 'do-not-reply' email in the mesg pane? Sorry, but you'll have to give me a
> step-by-step on that one...

I think file manager on Linux supports Drag&Drop of file to other application.
Try Drag&Drop of a .eml file at file manager on Linux to Tb's thread pane(mail list pane), please. Mail data in .eml file will be imported as a mail of Tb's mail folder.

Comment 6

[dline8es]

Wow, a "new" Bug 253830 from 2004!
Sorry: I did do a search, but didn't realize there was a distinct project for MIME (or originally that it specifically was a 'multipart/related' problem).
Seems like it might be fixed somewhere in 3.3x
Thanks - please mark as duplicate if I'm unable.

(Off-Topic)
I'm on kubuntu 8.04 and on dragging files, the mouse-pointer in TB looks like it's aware of the drag, but is 'X'ed suggesting TB doesn't want to take it.