Closed Bug 466674 Opened 16 years ago Closed 15 years ago

default action should be to send out html + plaintext w/o asking

Categories

(Thunderbird :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: clarkbw, Assigned: clarkbw)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

We should be sending out both HTML + Plaintext as the default sending option without asking.  Currently our default action for sending mail is to ask the person "How lucky do you feel?"  This dialog doesn't make much sense to a majority of users, the rest of the users who do understand should be able to find the preference to do what they want.

Currently the preference for sending HTML is turned on by default for Email and off by default for Newsgroups.  Therefore the effective change here is that email users won't see one less dialog while sending an email.

If newsgroup sending is somehow effected by this we should likely file a separate bug.  If for newsgroups we want to make this pref a per account pref that could be a possible future solution.
alternative patch in case SM wants this change as well
Assignee: nobody → clarkbw
Bryan, how does/should this affect our existing mechanisms to send only one type e.g. setting values in address book and sending out appropriately?
I'm not sure how the existing mechanisms work.  I think we want to minimize this dialog usage, perhaps remove it all together eventually... toward something more inline.

As I understand, switching from HTML to plaintext after the compose window has been created isn't easy.  Is this just because of formatting issues?  Though trying to alter the message compose area as a person enters email addresses isn't a great idea.

Here's how I'd assume the mechanism works, mostly automatic and informative when it needs to be.

If the set of recipients all require plaintext messages (according to their contact info) then I think we can silently send the message as plaintext only.  A person has to explicitly setup plaintext recipient modes and so I don't think there needs to be an indication of how the message is being sent.  This case seems a bit strange since a person has left HTML composition turned on, yet has specified plaintext for the set of current recipients; this might mean we should notify them how we're sending the mail out.

If the set of recipients is mixed requiring plaintext and unknown then we need to notify the user (perhaps an inline info bar) that the message will be sent as both plaintext and html.  For this use case a person has explicitly set some set of users and so likely cares about the format of mail being sent enough to want the notification and choice presented.

If the set of recipients is unknown or html then we should just be able to send the mail as plaintext + html without asking or even needing a notification.  For this use case, I believe is the most common, people don't really care or understand the consequences.  As such we should make what we believe is the best choice for them and not bother them with options they don't understand.

Mathematically there is room left for the set of HTML only recipients, however (and I could be wrong) I think it's good practice for us to always send both.  I don't think we need to handle this final case by only sending HTML mail.
The default_html_action pref is pretty much the last thing (literally) that we currently check when deciding how to send.

If you used the plain text composer, we send plain text only.

If you chose HTML, Text, or Both in the Options - Format menu (only present while composing HTML), we do what you said to do.

If you composed HTML and didn't pick something from the menu, then we look in the addressbook, and if anyone's preference is "Unknown" we're unknown, if 1 or more is HTML and 1 or more is Text we're unknown, if all are HTML or text then we're that.

If the AB gave us HTML, and there are no newsgroups, we send HTML only.

If any recipient is unknown or text, or there's a newsgroup, and we believe (not always perfectly correctly) that we can losslessly convert to text, we send text only (even if it enrages Nelson ala bug 414299).

If there's a newsgroup (and we haven't already decided to send text only), we ask no matter what, the default_html_action pref doesn't apply.

If there's no newsgroup, and everyone's AB card says they prefer text, then we silently lossily convert to text.

Then, finally, for the case where there's no newsgroup, and there's either one unknown preference or one each of HTML and text among the recipients, and we know that converting to text will be lossy, *then* we get to default_html_action.

But despite all that, this change is still certain to affect most cases, since if you compose in HTML because that's the default, and never put a choice of format in addressbook cards because, come on, what is this, the 1990s with people using an ancient version of pine? (or, put in text for your crazy uncle who *does* still use an ancient version of pine), and don't cross-post to newsgroups, then we'll always either silently convert to text, or use default_html_action, and it will not affect any part of "intelligent" send, because as you can see from http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#2896 there are no decisions after the pref-checking, they've all already been made.
Changing the default to silently send both plain-text and HTML would be a good move, I agree, at least for Thunderbird. That pop-up is confusing for a novice user who may have no clue what the difference is.

> (comment #4) ... and we believe (not always perfectly correctly) that we can
> losslessly convert to text, we send text only ...

Yes, Auto-Detect is sometimes too eager to down convert to plain text, thus there is bug 136502 to switch it off (personally, I compose in plain text by default and switch to HTML composition when I mean to it that way only), may be good to revisit that bug in the process.

If the dialog disappears, what happens with bug 44494 to remember the choice?
(In reply to comment #4)
> Then, finally, for the case where there's no newsgroup, and there's either one
> unknown preference or one each of HTML and text among the recipients, and we
> know that converting to text will be lossy, *then* we get to default_html_action.

I've given that scenario another thought with respect to the pine-using recipient. In the case "converting to text will be lossy" but not all recipients marked as "text only" the message would go out with both plain-text and HTML parts. Thus, in this worst-case scenario, the pine user would see the text/plain part first, which can be read in a non-HTML viewer, and then the text/html part would follow, which can be safely ignored as the message is read already. So, default_html_action=3 still looks like a good choice then, and the pine user may be annoyed but should be used to multipart/alternative messages.
One thing I'm mildly curious about: how do the major email clients reply to multipart/alternative messages (particular w.r.t. the text & html case)?

Reply in HTML only?

Reply in kind by editing in HTML, downsampling to text, and sending out multipart/alternative?

Some other variant(s)?

I'm not sure whether the answers to the above questions would actually effect any decision about this bug, so it may not be worth spending time worrying about.
(In reply to comment #5)
> Changing the default to silently send both plain-text and HTML would be a good
> move, I agree, at least for Thunderbird. That pop-up is confusing for a novice
> user who may have no clue what the difference is.

I think this is the best option.  Dan's comment 7 makes me wonder if we need to investigate possible issues with sending both.  However beyond that I think this is the most compatible option; the only downside being that we're sending a message twice.

> > (comment #4) ... and we believe (not always perfectly correctly) that we can
> > losslessly convert to text, we send text only ...
> 
> Yes, Auto-Detect is sometimes too eager to down convert to plain text, thus
> there is bug 136502 to switch it off (personally, I compose in plain text by
> default and switch to HTML composition when I mean to it that way only), may be
> good to revisit that bug in the process.

I (as always) want to avoid setting more preferences for people to get things done correctly.  Preferences are often hard to find and hard to understand the consequences.  If we're faced with adding a preference to solve a difficult choice for the user we are attacking the problem incorrectly.

Not to get into bug 414299 too much, but my gut says that most people just don't see their own mails after they have been sent.  If they do see their mail it's been changed by another client in the reply.

> If the dialog disappears, what happens with bug 44494 to remember the choice?

That bug seems a bit too complex.  The consequences of the preference are beyond what I believe the average person would really understand.  Again, I'm not saying that people are stupid, but if we're going to be automatic about choices we should just try to be that.  Giving the option to "automatically do things if you want" is not a good option.

Since, as phil points out in Comment #4, pretty much all the choices have been made in the code (some of which I'd question) by the time we get to this dialog question; perhaps this is just about sending both or sending html only.  Essentially mailnews already down converts everything it has hard coded to understand should want plain text, so the last option available is really to send as both or html.  

Unless Dan's point is correct about issues sending both formats then I think we should default to both for compatibility with our crazy uncles.  But now that I understand the workings of the Thunderbird code for sending it probably wouldn't matter if we switched to HTML only either.
With respect to the HTML-only vs. HTML+text option, keep in mind that spam filters include those in determining the spam score (apparently, spammers use HTML-only mails, mostly). SpamAssassin has a rule MIME_HTML_ONLY, which by default receives a score between 1.457 and 2.299. Thus, as long as both parts are "sufficiently identical", sending both text and HTML would be the best option with regard to minimizing the spam score.
Comment on attachment 349987 [details] [diff] [review]
html default action patch ( all-thunderbird override )

This seems like it has sat for long enough.  I'd like to at least get the TB pref change pushed through.

Attachment 349988 [details] [diff] has the mailnews one if that is wanted as well (not that a patch is really needed for this dynamic of a change).

philor, can you take a look at this for me.
Attachment #349987 - Flags: review?(philringnalda)
This is a high, and cheap, usability gain.
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b2
Attachment #349987 - Flags: review?(philringnalda) → review+
http://hg.mozilla.org/comm-central/rev/6881e0277872
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Guys, please, if you change shared defaults: tell us.
We don't want this default in SeaMonkey! :-(
(In reply to comment #13)
> Guys, please, if you change shared defaults: tell us.
> We don't want this default in SeaMonkey! :-(

Forget it, Phil checked in the right patch. :-)
(In reply to comment #7)
> One thing I'm mildly curious about: how do the major email clients reply to
> multipart/alternative messages (particular w.r.t. the text & html case)?

Has this question been addressed?

When we send out HTML + Text:

1. What happens when the recipient replies to our HTML + Text e-mail? Does the e-mail contain two copies of our text (one of them possibly garbled)?

2. What happens when the recipient forwards our HTML + Text e-mail? Does the e-mail contain two copies of our text (one of them possibly garbled)?

3. What are the answers to 1 & 2 for all the major e-mail programs (OutLook, OutLook Express, AOL, etc.) and web-based e-mail sites (gmail, Yahoo, etc.)?

PS. I don't know how many calls I've had from my parents and sister asking me how to answer that annoying dialog. This bug will be a huge improvement. :-)
How DO I send HTML email SANS Plain Text alternative?
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
PMJI, I may be OT, but in many cases I am sure my recipient is using HTML and the PTA (Plain Text Alternative) will just add 40% to the volume, with no benefit to anyone.

Now if all spammers had to do to bypass filters would be to include a PTA, sure they would; so this should NOT be an argument in one side or another.

So I ask: anyone can tell me how, using a mainstream mail client as OE or TB, I compose and send an email message in HTML *WITHOUT* a PTA? I know well how to remove the PTA from a received or sent message, but not from a message *being sent*. TIA,

Versailles, Thu 7 May 2009 15:31:20 +0200
(In reply to Michel Merlin from comment #17)
> How DO I send HTML email SANS Plain Text alternative?
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> PMJI, I may be OT, but in many cases I am sure my recipient is using HTML
> and the PTA (Plain Text Alternative) will just add 40% to the volume, with
> no benefit to anyone.

+1

> Now if all spammers had to do to bypass filters would be to include a PTA,
> sure they would; so this should NOT be an argument in one side or another.

+1

> So I ask: anyone can tell me how, using a mainstream mail client as OE or
> TB, I compose and send an email message in HTML *WITHOUT* a PTA? I know well
> how to remove the PTA from a received or sent message, but not from a
> message *being sent*. TIA,

Answer:

* On a per-message base while composing, you can use Options > Delivery Format > Rich Text (HTML) only
* For a more permanent setting, try this:
Tools > Options > Composition > General > Configure Text Format behaviour > [Send Options...] > Text Format: From the dropdown, choose "Send the message in HTML anyway"
* Also, try editing your AB contact cards and on Contact tab, set "Prefers to receive messages formatted as" to "HTML".

And yes, the whole algorithm of Text vs. HTML settings is a UX-nightmare and far too heavily tilted in favor of plaintext. Many bugs have been filed but it's a can of worms, complex to understand, not easy to fix, and subject to discussion.
You need to log in before you can comment on or make changes to this bug.