162554 - Auto collect "prefers html" info

Status: RESOLVED INVALID

(MailNews Core :: Composition, enhancement)

Description

[(not reading, please use [e-mail] instead)]

RFE:  auto collect "prefers html" info

recently I've been trading emails from someone who is sending me html email.

every time I reply to them, it asks me "send in html?"

it seems like if I get an email from someone, and it is in html, and they are 
in my addressbook (personal?  collected?  both?) and I have "unknown" for 
prefers html (so not html and not plain text), we should mark it as prefers 
html.

comments?

Comment 1

[David :Bienvenu]

sure, yes, we've talked about this in the past. We'd probably need to get a
little more info from mime when populating the history ab to do this. I'm not
sure if Mime has finished parsing the message or not by the time it gives us the
headers - if not, we'd probably need to postpone the notification until it had
finished parsing the message and thus knew if the msg was html.

Comment 2

[Jean-Francois Ducarroz]

I am pretty sure mime is done parsing the headers at this point, therefore it
wil be trivial to retreive the needed info...

Comment 3

[Mike Cowperthwaite]

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

Comment 4

[Thomas D. (:thomas8)]

(In reply to (not reading, please use [e-mail] instead) from comment #0)
> RFE:  auto collect "prefers html" info
> 
> recently I've been trading emails from someone who is sending me html email.
> 
> every time I reply to them, it asks me "send in html?"

TB has long stopped using "Ask me" as default setting. Which removes the main scenario of this bug.

> it seems like if I get an email from someone, and it is in html, and they are 
> in my addressbook (personal?  collected?  both?) and I have "unknown" for 
> prefers html (so not html and not plain text), we should mark it as prefers 
> html. comments?

I think this bug is trying to solve problems which no longer exist.
This hasn't had any supporting comments nor duplicates nor votes since 2002 when it was filed.
I think adding more complexity to recipient-centric logic is no longer needed nor wanted, because sending HTML is no longer a big deal. The general assumption in 2015 is that everyone can receive HTML; for those few who can't or don't want, user can set "prefers-plain" per-recipient or per-domain.
So we should offer the user general settings to default to sending HTML, or both plain text and html.

Two better solutions:

1) Recipient-centric: Allow global mapping of "prefers-unknown" to "prefers-something" (plain|html|both; Bug 1222176).

2) Message-centric: Allow per-identity setting of stable default-delivery format for new compositions (auto-detect | plain(?) | html | both). Along bug 136502, but we have morphed that into "switch for auto-downgrade", so there's no clean bug yet. Something like "Default message delivery format" option seen at the top of attachment 8673807 [details].

So I think this bug can be closed. Any objections?

Comment 5

[Thomas D. (:thomas8)]

This is essentially a duplicate of bug 306303, which has a more detailed but still insufficient description. So my comment on the other bug also applies here.

(In reply to Thomas D. from bug 306303 comment #14)

> - "Ask me" is no longer the default, so the main motivation of this bug (to
> avoid the nagging) is gone.
> - We have Auto-Downgrade for sending simple HTML messages as plaintext (when
> they look like plaintext because there's virtually no HTML formatting).
> - For all other types of messages (non-trivial HTML), most users just want/need to
> send HTML from HTML compositions, to preserve the formatting (UX-wysiwyg).
> - In 2015, HTML is no longer a problematic send format
> - In view of the above, switching every contact explicitly to "prefers-HTML"
> isn't necessary nor helpful, when all we originally wanted here is to "just
> let me send HTML without getting asked".
> Per-Recipient settings are a very clumsy and hard-to-reverse way of
> achieving that.

Instead (kinda reversing the idea of this bug), user should explicitly set "prefers-plain" for those few recipients (if any) who *cannot* handle HTML; for any other recipients, we can safely assume that they can handle HTML, and allow the user to default to sending that (with or without Auto-Downgrading when particular message has virtually no formatting).

> And if we are very honest, since everybody can receive HTML messages (even
> when some devices might downgrade them for the recipient) nobody cares much
> about the recipient's actual preferences.
> It's much more message-centric these days, so if my message content requires
> HTML formatting, I'll just send that without thinking about recipients.