Using 2000-02-18-08m14 commercial builds all platforms The HTML Intelligent send dialog displays when sending a message from html compose window when message content composed with no html properties (i.e. plain text, no bold lettering, italics, color, etc.). 1. Edit|Account Settings, set your mail account with "compose messages with html" enabled/checkmarked. 2. Edit|Preferences|Mail&newsgroups|Formatting and make sure the first pref is selected "ask me what to do if the message has html formatting..." 3. Open a new message compose window. 4. Type a letter or two in the body, apply no html formatting properties to the text. No bold, italics, color, etc. 5. Address the message to fooman@foobar.foo. 6. Send the message. Result: HTML intelligent send dialog appears when there is no (intended) html formatting present in the message. Expected: Should send without HTML question dialog appearing.

*** Bug 28423 has been marked as a duplicate of this bug. ***

Mass moving to M16 to get these off the M15 radar. Please let me know if this is really an M15 stopper.

> Expected: Should send without HTML question dialog appearing. To clarify, if all of the recipients are not known to like HTML, the expected result is that we convert the message to text/plain and send that. If all of the recipients are known to like HTML, we can send the message as text/html.

Not M16 stopper. Marking M17.

nsbeta2 nomination - this is a *very* important interop feature (Phil, you remember? :-) ) and has to be implemented carefully. b(old), strong, i(talic), em(phasis), u(nderline) and code are converted to the plain text correspondants (*bold*, *strong*, /italic/, /emphasis/, _underline_ and |code|) during HTML->TXT conversion. This is even recognized during display in Mozilla (TXT->HTML conversion) in most cases. Otherwise, the info is still there and a lot of people, who use plain text mail, understand it. Same applies for links (a-elements), which are converted to "link text <URI>". (In this case, there a *minimal* information loss, because you don't know, where the a element started, but that's all. The URI is there.) So, I suggest to not treat these elements as requiring HTML, since they don't really do anymore. They are the most.often used elements, so, as a result, the Ask dialog should come much less often. This is an advantage for the user (less annoyance) and the reader (higher compatibility). After all, this was the reason for me implementing the conversion features. J-F, is the 4.x code for "intelligent send" checked in (maybe in an |#ifdef|)? If yes, where? Tnx.

Why shouldn't bold (<B>), underline (<U>) and the others be treated as HTML when that's what it is. The map from bold to *text* might be obvious for an experienced mail/news user but that's by convention. Not because there is an equivalence. So treat bold as extended markup, which should be sent as html unless instructed otherwise, since html is the only way to ensure that the reader gets what's sent. You have to remember that most mail users will (probably) use some other MUA than Mozilla mailnews and for those it will be confusing to get *text* when the sender sent bold text and both are using MUA:s that understand html mail. The conversion from bold to *text* which is done in HTML->Text conversion is only to be used as the reserve plan, for use when the receiving can not accept html mail. I agree to the nsbeta2 nomination though. It's quite annoying to always be forced to fill in and close the dialog when working with mail without any extended markup.

> The conversion from bold to *text* which is done in HTML->Text conversion is > only to be used as the reserve plan, for use when the receiving can not accept > html mail. No, my idea was it to be used, whenever the recipient is not *known* to accept HTML. If we default to HTML for this markup, the feature is (mostly) useless.

Wait, I see the old discussion "assuming plain text or html" coming up again. Please see the thread in n.p.m.mail-news. People will often use bold etc. - if you propose HTML for this case, you create exactly the problem, we were discussing about. A compromise could be to open the Ask dialog and default to plain text, but I'd like to avoid this, since it's annoying. Users might disable intelligent send and default to HTML as a result. I think, what we really need is bug 27933 being fixed.

So you mean that if I write a mail to someone (not known to Mozilla) and uses bold, and italics I will not even be asked, but it will be converted to *text* and the like? That's not really good. Your assumption that the user always would choose html is not correct, but you'll piss some people off if you do the conversion without any chance for the user to influence that decision. Btw, the result isn't exactly what was sent even in mozilla I gather? You send <bold>This is bold text</bold> and get (in mozilla) <bold>*This is bold text*</bold>, which isn't the same. So, give the user the choice (the dialog) whenever any formatting Mozilla can't guarantee are understood by the receiver is used. That includes <bold>. What the default in the dialog should be, is of less importance. What's really important is that we don't do magic over the user's head when the magic isn't "perfect".

> without any chance for the user to influence that decision There are chances: - "Send HTML" in the address book cards. - Options | Format

Need phil input here...

I think we should have the whole algorithm working for "HTML intelligent send" for beta2. Otherwise, composing in HTML by default doesn't work well. nsbeta2+

J-F, what do you do with bold etc?

Fixed and checked in. The only tags that I don't care are: HTML, HEAD, BODY, P BR, PRE, BLOCKQUOTE (only when type="cite"), A (only when href is the same than the text inside the tag). If the document doesn't contain any other tags, we send the message in plain text without asking the user (only if not all the recipients accept HTML, else we send in HTML).

Filed bug 38433 about the structured phrases etc. J-F, div and span might also have to count as unproblematic. I'm still uncertain, but I might add divs and spans to quotes by default with bug 31906.

Linux (2000-05-19-08 M16) Win32 (2000-05-19-09 M16) Mac (2000-05-19-08 M16) I followed the scenario as described by Laurel. The bug is still there because the HTML dialog still comes up on all platforms. Re-open the bug.

Fenella, are you sure all your setting are correct? Try to send the message to the following recipient to be sure you don't have an entry for it in the AB that says Accept HTML: to: i@i.i

It's a case bug. We are comparing "html" with "HTML". I'll attach the patch that adds the IgnoreCase flag to the comparison. I also made the patterns lowercase. At least that saves a couple of clock cycles from the conversion. I guess this emerged because the mime module changed case on some elements generated.

Thanks Daniel! Reassign to rhp since ducarroz is on vacation.

Applying patch and doing verification build right now. Hope to check in later today. Thanks Daniel! - rhp

Should be fixed now. - rhp

Linux (2000-06-01-08 M16) Win32 (2000-06-01-09 M16) Mac (2000-06-01-08 M16) This problem is fixed.