Closed Bug 157346 Opened 22 years ago Closed 20 years ago

HTML format preference not honored for msgs without formatting

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 136502

People

(Reporter: bugzilla, Assigned: bugzilla)

Details

If I just write text and I don't apply any format (font, size, italic, bloc...)
the message is sent in plain text.

The config is set as follows:
- Mozilla->Prefences->Mail & Newsgroups->Send Format->Send the message in HTML
anyway. // Both domain lists are blank.

- Mail & News->Account Settings->Account Name->Compose messages in HTML format

- Compose->Options->Format->Auto-Detect

Build: 2002061104 (Mozilla 1.1 Alpha, fresh install)
Confirming with 2002071208/win2k, pref set to "send HTML anyway", although not
sure if it is really a bug. We automatically convert to plain text, if there's
no special formatting in the message. Ducarroz, what do you say on that?
To me, "send in HTML format anyways" means that the messages allways will be
sent in HTML.
Maybe that "auto-conversion" to plain text is there isn't any formating should
be an option?
Anyway, I think this situation can be very confussing for some users.

And, the problem I have with this is when I write text in russian (cyrilic), the
message is sent plain text without detecting the correct charset. As
consequence, neither reciever's mail client, neither Mail & News are capable of
interpreting the resulting message. [I'm using Mozilla in English and Windows in
Spanish].

Here's and example of the king of "uninterpretable" message:

From - Thu Jul 11 23:10:41 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
Message-ID: <3D2DF450.7080004@domain.com>
Date: Thu, 11 Jul 2002 23:10:40 +0200
From: "troodon@domain.com" <troodon@domain.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a) Gecko/20020611
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  recipient@domain.com
Subject: test
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

????, ?????, ????
??? ???????????????????????????????????????????????? ??? ?????? ???

These "?" characters where cyrilic characters. If this message is sent in HTML,
all is fine (charset, format).

Maybe this is just a charset-related bug?
I forgot to add that I have the same problem if I include in the message
romanian-specific characters.
And yes, it dispays the message saying the message cointains characters not
found in the selected charset, but shouldn't auto-detect Mail & News the correct
charset in plain text messages, like it does in HTML messages?

Anyway, all those charset-related problems wouldn't appear if all messages would
be sent in HTML formal.
Severity: major → normal
Even when "send the message in both plain text and html" is selected, Mozilla
(now I'm using build 2002101708) only sends plain text if there isn't any
formating in the message.
Troodon: in 1.3 Final, sending unformatted HTML mail as HTML ONLY or BOTH does 
in fact send it as directed; so I'm marking this message WorksForMe.

I don't know much about how alternate encodings.  If I paste Unicode characters 
in from the Character Map, then click Send, Mozilla prompts me to change the 
message coding; if I select UTF-8 and send it, the mail comes across as desired.

If you set the message's encoding via the menu, can't you use plain text and get 
the results you want?
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Please see comment #3 . I'm using 1.4b and it still sends messages in text
format by default. That isn't the behavior I expect. I want it to send messages
in HTML format always, without having to select Compose->Options->Format->HTML
only, because I already selected Prefences->Mail & Newsgroups->Send Format->Send
the message in HTML
anyway.
Mike, Troodon is right. The behaviour hasn't change since when this bug was
filed. See comment #2. With the additional note that "send HTML anyway" in
Preferences doesn't change the behaviour. A text without formatting is always
sent as Plain Text. Re-opening and marking as new. I might be wrong but I think
there is some inconsistency here.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
OK, I misread something; I thought the issue was that even the override (compose 
window, Options|Format) wasn't working, and it is.

I noticed a comment at some point while reading bugs this weekend that the 
conversion of unformatted HTML to plaintext was a deliberate design decision.

Troodon wrote:
> it dispays the message saying the message cointains characters not found
> in the selected charset, but shouldn't auto-detect Mail & News the correct
> charset in plain text messages, like it does in HTML messages?

My understanding is that warning appears when Unicode characters requiring two 
or more bytes have been entered into a message encoded with a single-byte 
charset.  If you select a default message encoding of Unicode/UTF-8, you won't 
get that problem, and still be able to send iso-8859-1 messages.

The HTML messages I tried sending with Unicode characters converted them all to 
entities -- such as &#260; -- so there is really no auto-detection of the 
charset being used here.

On the other hand, if you want to use an alternate 8-bit encoding, it doesn't 
seem that much to ask that you change the encoding of the message (say, to 
KOI8-R) before composing.  But I don't know how to compose mail in that mode.
Thanks for the character suggestions, I'll try them.  Anyway, the main problem
is with the sending format settings not working as expected. If it's a designs
decision, at least, the captions of the compose in HTML options should be
changed (I'm speapking about the preferences dialog).
*** Bug 210378 has been marked as a duplicate of this bug. ***
Reproduced on 1.4b RC2

Fully agreed with comment #7

Actually it works when doing "Compose->Options->Format->Rich Text (Html) only"
But it seems that there is no room in Preferences to set this properly to a
default behaviour different from "Auto-detect"
Is it ?
And setting this manually for each message is really a pain, especially when
settings seem to promise the opposite
(there is no value in preferences to set "Auto-detect" actually)
*** Bug 210693 has been marked as a duplicate of this bug. ***
I've done some testing with this using 1.4 (regarding bug 187064).  If no 
formatting is used during HTML composition *and* recipient's preference is 
unspecified, preference is ignored and message is sent plain; but if the 
recipient is specified as "prefers HTML," that's what gets sent.  

I'm not sure if that's how it was working in 1.3.

Nearly any use of formatting will result in HTML being sent (unless the 
preference or recipient's preference is against that).
After #13 comments:
first, thanks for reminding us about this setting in the address book

However, I would consider that this is part of the old times specifics that are
now pretty obsolete. Couldn't we have a less conservative behavior, where HTML
messages are sent in plain text only, only when all recipient have an explicit
preference for plain text ??

Or, even more radically different: always send in the format selected in
"Preferences / Mail & Newsgroups / send Format"
Actually, there are also HTML/plain text preferences per domain in these
settings. How do they interfere ? How do they combine with user level preferences ?

This looks to offer a huge complexity, creating a lot of opportunity for bugs,
with really few benefits !?
This is a truly annoying bug 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 discovered a bit of a workaround for this issue: if you change the default 
colors for HTML composition from black-on-white, that will count as an "HTML 
element" and the mail will not be downconverted to plain text -- unless the 
recipient is listed in the address book as Prefers Plain.  

If all recipients are listed as Prefers HTML, with an unknown preference, or 
unlisted, the mail will go out as HTML.  This is true with 1.5 Final and 1.6b; I 
don't know about earlier versions.

I also read on a newsgroup that, even if the default colors are used, if the 
message is saved to the Drafts folder and then reloaded, or created from an HTML 
template, then the message is sent as HTML (except to Prefers Plain recipients).

One problem is that if only one recipient of several is listed as Prefers Plain, 
the message is still downconverted.  This is properly part of bug 187064, since 
that conversion occurs even with substantial HTML content (such as an inline 
image).
I recall seeing the same problem on Mac and Linux. Please change Hardware and OS
to All.

Prog.
The same problem is apparent on my system. 2 different profiles. The setting to
send email in HTML format does not hold (save) under "Send Format" preferences
regardless of what is selected (HTML). If I select and change it it seems to
accept the change and when you begin to compose a message it appears to
format/write in HTML, but then sends in text and strips the HTML of any images,
colors, font styles, etc. 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/RTF each time a message is sent. No specific recipient's preferences
are specified. FYI: The prefs.js file seems correct respective to the preference
selected. Is there a permanent workaround for this? or can the compose menu
Option > Format selection be saved somehow so it defaults to HTML/RTF?
Driving me Batty!!!
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 
As I have written in comment 17, this bug is not Windows-specific. Marking as such.

Prog.
OS: Windows 98 → All
Hardware: PC → All
> One problem is that if only one recipient of several is listed as Prefers Plain, 
> the message is still downconverted.

No other way. If you set "prefers plain", that tells us that this recipient
can't receicve HTML mail, so we *must* send plaintext to him. We can't send
plaintext to *him only*, because only one mail for all recipients is sent to the
SMTP server.


As to this bug: It's a very concious decision to send plaintext only for msgs
without formatting, but I don't know, if there was a concious decision about
this particular combination (HTML preference, no formatting). One case is when
users want to send HTML when needed (when they used formatting), without being
asked every time, but still want to (or should) send plaintext in case where
it's not needed (no formatting). This use case would break when fixing this bug.
OTOH, I wasn't aware of the problems Hebrew users are facing (in fact,
left-to-right-support didn't exist back then), so this may be an argument. The
russion characters are no argument in my view, set the charset correctly (or
better yet file a bug why it wasn't set correctly automatically).
Summary: Messages aren't sent in HTML format → HTML format preference not honored for msgs without formatting

*** This bug has been marked as a duplicate of 136502 ***
Status: NEW → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → DUPLICATE
> "Send Format" preferences
> sends in text and strips the HTML of any images, colors, font styles, etc.

Not what I see. If I select HTML in prefs, the msg gets sent as HTML, if there
is formatting. If there is none, it's sent as plaintext. That is with a
recipient with unknown format preference in the address book. (Be sure to read
the Source of the sent mail, not just look at the display.)
About the bidi issue: shouldn't the dir="rtl" BODY attribute count as
formatting? I don't see a separate bug on this.

Correction to comment 23: this was filed and resolved (bug 228720).
(In reply to comment #20)
> OTOH, I wasn't aware of the problems Hebrew users are facing (in fact,
> left-to-right-support didn't exist back then), so this may be an argument. The
> russion characters are no argument in my view, set the charset correctly (or
> better yet file a bug why it wasn't set correctly automatically).

You're right, they aren't an argument and using UTF-8, as suggested in comment
#8 , that is solved. But that situation uncovered the MAIN point of this bug: an
option doesn't work as one would expect from its name and description. Also,
there is a really chaotic situation with the send format options, as there are
many options distibuted across many different places/menus, which may lead some
users to confusion.
> there is a really chaotic situation with the send format options, as there are
> many options distibuted across many different places/menus, which may lead some
> users to confusion.

Undoubtly
Product: MailNews → Core
Guys - the "if Seamonkey doesn't see any reason to use HTML, convert to Plain Text despite user's preference (or lack of preference)" is one of those nice, well-meant "the tool knows best" optimizations that causes endless nightmares because it is unanticipated behavior.  It really shouldn't be the default, and I'm guessing that removing this check should be a fairly easy and benign thing to do.  (Easy, because you just have to make the "can I convert to plain text?" check always fail, and benign, as no one who sets the preference (or has no preference) -expects- the message to go as plain text (no preference = no expectations)).  

So why not just remove the "can I convert this to plain text anyway" check for now.  Later, you could add an option to the Send Format options.

/j
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.