Open Bug 268159 Opened 20 years ago Updated 2 years ago

Certain replies appear to have no formatting but are not auto-converted to plain text (for "unknown" recipients)

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

People

(Reporter: mfedyk, Unassigned)

Details

Attachments

(1 file)

MBOX file of plain text message, and reply in plain text & html
6.60 KB, message/rfc822
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

I have this option set: tools -> optoins -> composition -> send options -> send
the message as both plain text and html

And this is set also: tools -> account settings -> composition & addressing ->
compose message in html format

I have a message that I received that was plain text, and replied to it and
didn't  use any formatting, except for the automatic colored vertical quoting lines.

Reproducible: Always
Steps to Reproduce:
1. Reply to plain text message
2. Do not make use any formatting (bold, larger text, etc)
3. Send

Actual Results:  
Outgoing message is in plain text & html.

Expected Results:  
Outgoing message should only be in plain text.
Forgot to put build ID: TB 0.9 (20041103)
What is the mail-type preference for the recipient in your address book?
Plain, HTML, or Unknown?  For a recipient with an unknown preference, the actual 
results are expected.
I never set those in the address book, and I think this message created a new
card for this person -- so it must be unknown.

Just checked the card, and it is "unknown".

So, now I have to set each card on who wants plain text and who wants html?

Why does the blue vertical quote line have to count as formatting?
(In reply to comment #3)
> So, now I have to set each card on who wants plain text and who wants html?

Afraid so; it is kind of a pain.  See bug 44494.


> Why does the blue vertical quote line have to count as formatting?

Y'know, I didn't read your bug report carefully enough -- that shouldn't count 
as formatting.  And when I just tried a simple test, it didn't -- my default 
option is "Ask me what to do" and replying in HTML to my "unknown" recipient did 
not generate the prompt.

However, when I replied to a text/plain (non-format=flowed) message with 
multiple levels of quotes, like the original message in your attachment, I *did* 
get the HTML Mail Question.  That makes a combination of nested <blockquote>s 
and <pre> text, which may be sufficiently complex to prevent automatic 
conversion to plain text.

A f=f, multiple-level-quote reply is silently converted to plain, and so is a 
non-f=f, single-level-quote reply,

However: a reply to an HTML mail, even a very simple one with no quotes, results 
in the HTML Mail Question appearing.  In my simple test case, the HTML which was 
not auto-converted looked like this:

<body bgcolor="#ffffff" text="#000000">
M Cowperthwaite wrote:
<blockquote cite="mid3F785663.4040208@toast.net" type="cite">
  <meta http-equiv="Content-Type" content="text/html;">
  <title></title>
Just some plain text.<br>

</blockquote>
Perfect!<br>
</body>

Maybe the <meta> or <title> tag that were (invalidly) included in the reply's 
<blockquote> was sufficient to trigger the "this message is formatted" flag.


I see these results in TB 0.9 and Moz 1.8a5-1019, Win2K.  Moving bug to 
MailNews.
Severity: enhancement → minor
Status: UNCONFIRMED → NEW
Component: Message Compose Window → Composition
Ever confirmed: true
Product: Thunderbird → MailNews
Summary: If replying to plain text message and mode is "send as plain text & HTML" and there is no formatting then only send as plain text → Certain replies appear to have no formatting but are not auto-converted to plain text (for "unknown" recipients)
Version: unspecified → Trunk
Product: MailNews → Core
Assignee: mscott → nobody
QA Contact: composition
Product: Core → MailNews Core
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: