Closed Bug 187064 Opened 22 years ago Closed 21 years ago

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

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: phnyx, Assigned: bugzilla)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

sample of email from "drafts" folder showing graphic
17.49 KB, image/gif
Details
sample from email as sent and stored in "sent" folder
2.06 KB, image/gif
Details
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: 21 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: