Closed Bug 187064 Opened 22 years ago Closed 20 years ago

"Send Format" preference ignored, mail always converted to plain text for Prefers Plain recipients

Categories

(MailNews Core :: Composition, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: phnyx, Assigned: bugzilla)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

1: 
Preferences => Send format set to "Ask me what to do":
Recepient set to "Prefers... unknown" or set to "Prefers... plain text".
Mozilla doesn't prompt what format to send in, but sends in plain text in any case. 
Mozilla sends in plain text even if recepient set to "Prefers... HTML".

2:
Preferences => Send format set to "Send the message in HTML anyway":
Message is sent in txt-format to recepients set to "prefers... plain text".

Reproducible: Always

Steps to Reproduce:
1.1:Preferences => Send format set to "Ask me what to do"
1.2:Recepient set to "Prefers... unknown" or set to "Prefers... plain text"
1.3:Send message in html-format (image inline).

2.1:Preferences => Send format set to "Send the message in HTML anyway"
2.2:Recepient set to "Prefers... plain text"
2.3:Send message in html-format (image inline).
Actual Results:  
Message sent in text-format.

Expected Results:  
1: Mozilla should prompt whether to send message in text- og in HTML-format.
If recepient set to "Prefers... HTML", message should be sent in HTML-format
without prompting.

2: Message should be sent in HTML-format.
Severity: normal → major
In the first case, there is no point in sending a plain text file as HTMl since
it needlessly wastes bandwidth by adding unnecessary HTML fluff.  If you add
formatting, you should be prompted to send in the user's desired format.
Reporter has clarified via e-mail that in the first case is is sending as plain
text even if formatted for HTML.  Reporter, when you respond, please respond to
the bug and not the Bugzilla e-mail message.

When I reread your initial report, you are including a picture.  Is the problem
happening with other HTML formatting, changing font for example?  If a picture
is the only HTML-like thing, Mozilla might be including it as an attachment or
something like that.  I think that might be a know bug, not sure.
I am having the same problem with Bld ID: 2003060409 -- I am not getting the
prompt even though I have configured to get the prompt.  All mail goes out as
text.  

Since I have not had this problem before with other builds, I'll try a new
version -- I'll download the latest and greatest and see if the problem
continues to occur.
I downloaded and installed Bld 2003061108.  It did not solve my problems.  I am
attaching to graphics:  the first showing my email with a graphic attached (from
the "drafts" folder), and the 2nd from the email that was sent (which does not
show any graphic at all).  The Preferences / Mail & Newsgroups / Send Format is
checked for "Ask Me what To Do".  I was never asked and the mail went out as
trext only.
I sent out the same message a third time -- BUT after changing the "send format"
to "Send in HTML anyway" and it went out just fine!  Obviously the prompt is not
working:  it is not sending out the prompt message!
S. Green, I assure you that your comments are present.  As for whether the
esther@netscape.com address is correct and working, I don't know.
This appears to be a duplicate of bug 157346.
re Comment #9:  I reviewed bug 157346 and I disagree that this is the same
thing. On my system, I have Mozilla congured to always ask me what format to
send.  I am NEVER being asked! and the message ALWAYS goes out as text.  When I
changed the config to always send as HTML, the messages are always formatted and
sent as HTML.  It is the prompt message (and its subsequent process) that I am
not getting.
S Green: You did not open this bug.  Reporter mentioned both the symptom you 
specifically are having, and a symptom more similar to that described in bug 
157346, with the preference set to "Send as HTML anyway."  To my mind, the 
problem is that the preference is being bypassed, rather than that the prompt is 
not being shown.

However, I'm confirming this because that bug does not talk about dropping 
images or other complex elements; it seems to be primarily about HTML-but- 
unformatted messages being converted to plain text despite the "Send as HTML 
anyway" setting.

Besides: (a) I've seen HTML mail with images converted to plain text myself, and 
(b) I've got a couple of dupes lined up for it.  However, I did just try to 
reproduce the problem, in 1.3 Final and 1.4RC2, and was unable to; even an HTML 
mail with just one word styled to Bold resulted in the prompt, let alone for 
elements like tables and images.

Also, I'm rewording the summary to a summary rather than a paragraph.  Kim Gjøl, 
I hope the summary is correct from your perspective.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: message is sent in txt-format to recepients set to "prefers... plain text" No prompt ever even if I send html mail to recipient set to "plain text" ot "unknown" as preferred format in addressbook (Send format set to "Ask me..." in freferences). Also if… → "Send Format" preference apparently ignored, mail always converted to plain text regardless of recipient's preference
Altho this is not the source of Kim's problem, the fix for bug 202561 (which was 
checked in 28-Apr-03) might be behind the more recent problems (S.Green's issue 
here and the two potential dupes, bug 204035 and bug 208939).
*** Bug 208939 has been marked as a duplicate of this bug. ***
*** Bug 204035 has been marked as a duplicate of this bug. ***
Copied from bug 204035 
> I always have my default set to send as html, but on frequent occasions
> it sends it as plain text.  I think it seems to do this when I send to
> domains both in and out of the corporate @lucent.com domain.  (@lucent.com
> is also listed in the preferences as "always html")

Adding 'regression' keyword, because this used to work.
Keywords: regression
I tested win32 Mozilla v. 1.3.1 for same bug.
*Regardless* of Recipient preferences you are allways prompted whether to send a
 html-formatted mail in html. Even if recipient is marked in address book as
preferring html.
AND in ANY case the mail is sent in plain text.
In one instance the mail was sent as a mysterious mix with bold text correctly
in bold but with plain text "bold markers", i.e. with * in front and after the
bold text.
I've run some tests on this bug recently with 1.4 Final and it seems to me the 
preference is now working.  Even with just one bit simple formatting (bold or 
italic), I find that:
 - With the preference set to "Send HTML anyway", the original HTML is being 
sent on as HTML unless the recipient is specifically marked as "prefers plain 
text"
 - With the preference set to "ask me", I am prompted for the "unspecified" 
recipients, and the recipient's preference for HTML or text is being used.

Kim Gjøl, is it working OK for you?  If so, please mark this bug as 
Resolved | WorksForMe.
confirming for:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718
(also happened with 1.4 final)

The bug is still there if you insert just one image (not attached of course) and
type in some text afterwards. If the recipient is marked as "prefers plain
text", no dialog comes up but the image is dumped and lost when sending the mail.
I was going to say that is the expected behavior for "prefers plain text" -- but 
on rereading, I see the Send Format preference page reads:
  When sending message in HTML format and one or more recipients are 
  *not listed as being able to receive HTML*: ...
which should include recipients marked as preferring plain text.

The Send Format preference is ignored, and mail converted to plain, for 
recipients known to prefer plain text, but not for those who are unspecified or 
unlisted.  If this is the desired behavior, the wording on the Preference page 
(and associated help) should be changed.

The loss of image in conversion to plaintext is bug 180997 (and see bug 66035, a 
long but enlightening discussion); but this bug is about whether the preference 
is adhered to.
*** Bug 215104 has been marked as a duplicate of this bug. ***
It is now 2 months later and I am now running Build 1.5b 20030808 and the mail
program did not send my message as HTML even tho PREFERENCES are set to "send as
HTML anyway" and OPTIONS | FORMAT is "auto-detect".  My message had formatted
text and an embedded graphic.  

I sent it a 2nd time okay with OPTIONS | FORMAT set to "Rich Text (HTML) only".

I really think tha this bug has to be fixed.  The user (ME!) has to have
confidence that the message will be sent in the manner expected.......
Just tested:
In release 1.4 this bug is still not fixed.
Like Bug 157346, this is annoying for users of Hebrew and Arabic, as even
setting a different formatting (dir="rtl" for the body of the email) isn't
enough, and the
mail gets sent as plain text.

As a workaround, I italicize a single space. This forces Mozilla to send the
mail as HTML.

Prog.
I just did a little more testing, using 1.5RC1.  I have found that, when 
composing a message in HTML:

 - if the message has no HTML elements, it will be sent as plain text unless 
   the recipient is listed in the address book as "prefers HTML mail".  (This 
   is the problem described by "prognathus" in comment 23.)

 - if the recipient of the mail is listed in the address book as "prefers plain
   text mail" the message will be sent as plain text, regardless of its content.

In my view, the first item is bug 157346, the second item is this bug.  The 
behavior regarding this bug *has* improved as of 1.4 because now, for a 
recipient listed as "Prefers... unknown", the mail is not automatically 
converted.  (This is probably due to changes made for bug 107877.)

This bug is more important because an image can be lost unexpectedly when sent 
to a "prefers plain text" address.  As I noted previously, bug 180997 makes the 
loss of the image especially egregious; but really, there is no excuse for ever 
converting the image to plaintext without warning, regardless of the preference 
of the recipient.
*** Bug 220981 has been marked as a duplicate of this bug. ***
I'm updating the summary to reflect my results described in comment 24.

The duplicate bug report raised an issue that has not been mentioned here: if 
sending to multiple recipients, who are listed with different "prefers xxx mail" 
settings.

In my testing, sending HTML mail (with formatting or HTML elements) to two 
recipients, one of whom "prefers plain text" and the other either "prefers HTML" 
or is unknown, Mozilla abides by the Send Format preference, and then sends the 
HTML mail [1] to both recipients.

[1] Actually, the resulting email could be plain-text mail, if the Send Format 
preference is "Send as Plain" or if the preference is "Prompt me" and the result 
of the prompt is "Send as Plain."

If anyone following this bug has data contradicting my comment 24 or this 
comment, please do post.  There are a lot of different settings in Mozilla that 
affect this bug, and I don't claim my testing is complete.
Summary: "Send Format" preference apparently ignored, mail always converted to plain text regardless of recipient's preference → "Send Format" preference ignored, mail always converted to plain text for Prefers Plain recipients
I believe I was mistaken in comment 26: I now see that if any recipient is 
listed as Prefers Plain, the message is converted and sent as plain to all 
recipients.  I'm not sure what I saw that led me to the opposite conclusion.

This particular symptom is bug 137666.
*** Bug 214317 has been marked as a duplicate of this bug. ***
Also related is Bug 136502 - "Provide prefs. setting to turn off Options ->
Format -> Auto-Detect".

Such a pref could make things much easier, as it would allow users to force
Mozilla to send a multipart mail (HTML + Plain Text), regardless of Auto-Detect
shortcomings.

Prog.
The same problem is apparent on my system. The preference to send email in HTML
format does not hold (save) under "Send Format". If I select and change it it
seems to accept the change, and when you begin to compose a message it writes in
HTML, but then sends in text and strips the HTML. To work around this I have to
first go to the options > format menu where it indicates "auto detect" as the
default then have to select HTML each time a message is sent. Is there a
permanenet workaround for this? or can the compose menu Option > Format
selection be saved somehow so it defaults to HTML? Driving me Batty!!!
Greg Chakalian
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 
Greg, as a workaround, you can italicize a single space. This will force Mozilla
to send the mail as HTML. To make it permanent, use templates.

Prog.
Greg's issue is bug 157346, since he doesn't have any address book entries set 
up with Prefers Plain.

As I noted in bug 157346 comment 16, a workaround is to set the colors for HTML 
composition to something other than the defaults.  However, that doesn't 
override this bug's problem of forcing a downconversion based on a single 
recipient's "Prefers Mail As Plain" setting.
The bug as stated in the summary is INVALID, IMO. If you set "prefers plaintext"
in the recipient's address book card, you tell us that this recipient can't
receive/read HTML and we thus *must* use plaintext. Your general preference
won't make any difference. Why are you setting "prefers plaintext", when you
want all mails, without exception, going out as HTML? But see below.


> I have Mozilla congured to always ask me what format to
> send.  I am NEVER being asked! and the message ALWAYS goes out as text.

"Ask" means "ask, when we don't know what to do", not "always ask". If there's
no formatting (<img> should count as formatting, IIRC), there's no problem, we
can send as plaintext without losing anything and won't bother the user. This is
by design and changing it would annoy the heck out of almost all users.

> This bug is more important because an image can be lost unexpectedly when sent 
> to a "prefers plain text" address.

Should not happen. This is bug 180997.

> but really, there is no excuse for ever converting the image to plaintext
> without warning, regardless of the preference of the recipient.

What are we supposed to do? The recipient can only receive plaintext, it doesn't
make sense to send as HTML, so it doesn't make much sense to ask the user if we
should send as HTML. THe only sensible options are to send as plaintext or to
throw the user back into the composer to "fix" the msg (remove formatting,
express differently).

However, IIRC, we used to do ask the user, if he wants to send as HTML anyways,
at least for multiple recipients where one can only receive plaintext, the
others can read HTML (or are unknown) and there's formamtting in the mail. This
may be a regression, I don't know. But this never made much sense to me
personally, IIRC. In any case, I'd file a new bug about this, because this one
is too messed up already. This case has nothing to do with your preferences,
only with the msg content and recipient settings.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
> However, IIRC, we used to do ask the user, if he wants to send as HTML anyways,
> at least for multiple recipients where one can only receive plaintext

I just checked (I forgot that my own preference was to always send plaintext)
and it indeed asks which format to use, if any of the recipients are
plaintext-only and the msg contains formatting. I personally think that doesn't
make sense (why gve the option to send HTML, if the recipient can only read
plaintext?), but solves your problem in one way.
See bug 243133 -- a patch has been checked in which forces the "HTML Question" 
prompt in the case of mixed "prefers plain" and other addressees.

People with votes on this bug should move them to another bug they'd like to see 
fixed.  (email me if you need suggestions... :)
Maybe this isn't worth mentioning, but there is some additional clarification to 
an earlier comment in this bug:

(In reply to comment #27)
> I believe I was mistaken in comment 26: I now see that if any recipient is 
> listed as Prefers Plain, the message is converted and sent as plain to all 
> recipients.  I'm not sure what I saw that led me to the opposite conclusion.

What I have recently discovered, which is true back to 1.5 if not earlier, is 
that an *unlisted* recipient is handled as "prefers plain" rather than 
"unknown".  I've opened bug 257686 for this issue.

And: if a recipient is listed as Unknown, that will cause the Send Format 
preference to be applied even if another recipient Prefers Plain; but, at the 
time this bug was active, having a mix of Plain and HTML recipients would result 
in silent conversion (bug 243133, fixed in 1.7 and TB0.7).

I'm sure that being unaware of these two behaviors led to the conflict between 
comment 24 and comment 26.
*** Bug 265657 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: