171804 - Mail/News acct setting: Checkbox for composing mails in HTML format doesn't work

Status: VERIFIED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Jeesun Cho]

Mail/News acct setting: Checkbox for composing mails in HTML format doesn't work
Build: 0930 Trunk

Steps:
1. Open Mail & News Account Settings
2. Go to any mail account either POP or IMAP. Make sure the checkbox for
"Compose messages in HTML format" is checked (checked by default)
3. Send a msg and Receive it
4. Message is composed in Text format, not HTML

Comment 1

[Jeesun Cho]

Nominating for the next release.

Comment 2

[esther]

I'm using the 9-30 trunk on winxp and don't see this.  Am I missing a step?  

Comment 3

[esther]

Is this specific to an international build or character set?

Comment 4

[Jean-Francois Ducarroz]

does the compose window you get has the formating toolbar? My guess is that you
correctly get an HTML compose window but the message is send as plaintext! There
is many factor that can force Mozilla to send the message as plain text instead
of HTML...

Comment 5

[Jeesun Cho]

I tried this using a clean installation and new profile. I created a webmail and
AOL account. It works fine for me.
Probably my old profile had some problem.

I guess it'll also work for POP/IMAP account even though I couldn't confirm it
because there's another bug which prevents me from creating a new POP/IMAP account. 

Making this WFM

Comment 6

[Jeesun Cho]

Mark this as verified

Comment 7

[Ben Bucksch (:BenB)]

This bug is invalid. The pref mentioned is for the composer used. It's different
from the format actually used during sending. THe latter depends on what you do
in the composer. If there's no formatting, you'll get plaintext. same behaviour
in 4.x.

Comment 8

[Jeesun Cho]

Reopen this only on mac osx.
I saw this on us branch build on mac osx. Not reproducible on windows build.

>does the compose window you get has the formating toolbar? My guess is that you
>correctly get an HTML compose window but the message is send as plaintext! 

Yes. I see the formatting bar in the compose window. 

>THe latter depends on what you do in the composer. If there's no formatting,
>you'll get plaintext. same behaviour in 4.x.

On windows platform, even though I did NOT use any formatting (bullet items
etc.), when I sent a msg and received it, it was composed as HTML file as
expected (which is the default setting)

Comment 9

[marina]

Jeesun, we are not looking into 1.0 branchany more. The automation is still
producing these builds but we are testing the trunk. The 1.0 branch stopped
11/20 and no fixes are going to be checked into this branch. Please compare to
the trunk.

Comment 10

[Jeesun Cho]

Definitely... I'll check this out on trunk.

Comment 11

[jglick]

Reporter, is this a problem on the Trunk?

Comment 12

[Gayatri Rimola]

Esther, 
pls. reproduce this bug on Mac OS X and update the bug. Thanks.

Comment 13

[Jeesun Cho]

Using 1217 trunk build on macosx, I was able to see the same problem only when I
received msgs in POP account, but not in IMAP.
Both IMAP and POP accounts have the default preference for composing(compose msg
in html format)
(You send a mail)
(From)-(To)
POP -> POP   : problem exists (msg in text format)
IMAP -> POP  : problem exists (msg in text format)
IMAP - IMAP  : no problem (msg in html format)
POP -> IMAP  : no problem (msg in html format)

Comment 14

[esther]

Using the 12-27-2002 trunk build on mac osx 10.2 and a profile with an IMAP and
POP account.  Both set to compose in HTML I composed msgs and added HTML
attributes then sent them.  All these scenarios passed when msg was received and
viewed.  I will check with jeesun to see if there is a criteria missing from
this scenario. 
(From)-(To)
POP -> POP   : no problem (msg in html format)
IMAP -> POP  : no problem (msg in html format)
IMAP - IMAP  : no problem (msg in html format)
POP -> IMAP  : no problem (msg in html format)

Comment 15

[Jeesun Cho]

>I composed msgs and added HTML attributes then sent them
I didn't add any HTML attributes in msgs when I saw the problem. 

When adding those HTML attributes (e.g. make a bullet item), it asks me to
choose a format option (send in plain text and html, send in plain text only,
send in html only). I chose the third one , then all scenarios passed for me too.

Comment 16

[marina]

i used the 123008 trunk build on MAcOSX (10.1)to test and here are the results:
POP -> POP   : no problem (msg in html format)
IMAP -> POP  : no problem (msg in html format)
IMAP - IMAP  : no problem (msg in html format)
POP -> IMAP  : no problem (msg in html format)

Comment 17

[esther]

Jeesun is viewing the source to see the the content type.  She's seeing
text/plain when the compose window she's using is the HTML compose window to
compose.  It should be text/html.  I don't see the problem so I am working with
her to find out what's different betweem our 2 systems/profiles.  

Comment 18

[marina]

i used the Message source also to be sure that the message was an html vs plain.

Comment 19

[Jeesun Cho]

Using OTHER mail test server, all testcases passed.

Esther and I determined that the mail server I used (polyglot, 4.x messaging
server) might have some problem. 
I verified that using this server, no matter whether it's an IMAP or POP
account, I saw the problem on both Mac and Windows.

Comment 20

[marina]

we never used polyglot to test mail. Polyglot is an LDAP server and was used to
test AB

Comment 21

[Jeesun Cho]

I always used polyglot as a mail test server along with other servers. Xianglan
setup an account for me and we thought that it'd be good to include a 4.x
messaging server in our testcases.

Comment 22

[esther]

Polyglot server you used is a "Netscape Messaging Server 3.5" (this was taken
from the source of the email message that has the problem). This is not on the
list of servers we support per jhooker.  You should probably use another server
for testing.  Removing the nomination.  This bug is probably invalid.  

Comment 23

[Jeesun Cho]

Ooops, yes it's 3.x, the old one, not 4.x. We also need to decide if we don't
need to use 3.x mail servers any more.

Comment 24

[esther]

OK, more investigation finds this is working as it should.  The problem is not
with the server.  This is a misunderstanding of the send format option.  In this
case, the domain polyglot.mcom.com was not listed in the Send format preference
as being able to use html. Nor was the recipient's address listed as being able
to use html. Therefore, we sent in plain text.  Once polyglot.mcom.com was
listed in the HTML portion of the preference for Send Format this worked fine. 
Resolving as worksforme and verifying.

Comment 25

[esther]

verifying