Closed Bug 1228846 Opened 8 years ago Closed 2 years ago

Implement message-centric 'Default Message Delivery Format' setting (e.g. 'Always HTML') for new compositions to bypass Auto-Detect logic completely (which is prevalently recipient-centric)

Categories

(MailNews Core :: Composition, enhancement)

enhancement
Not set
normal

Tracking

(firefox45 affected, thunderbird_esr91 wontfix)

RESOLVED FIXED
101 Branch
Tracking Status
firefox45 --- affected
thunderbird_esr91 --- wontfix

People

(Reporter: thomas8, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: ux-control, ux-efficiency, Whiteboard: [fixed by bug 1727493])

User Story

Options > Delivery Format menu currently offers 4 flavors:
0) Auto-Detect
1) Plain Text only
2) Rich Text (HTML) only
3) Both Plain and Rich (HTML) Text

We're forcing users to start each message with Auto-Detect (which also includes Auto-Downgrade to plaintext for simple messages).

Auto-Detect is prevalently recipient-centric (send what the recipient prefers), with a message-centric appendix of Auto-Downgrade (send plaintext when the message looks like plaintext).

Worse, current send option which controls auto-detect, claims to be recipient-centric (When... one or more recipients are not listed as being able to receive HTML), but in reality it's a weird conglomerate of:
a) recipient-centric conflict resolution for somePlain recipient scope: messages where some, but not all of the recipients prefer plain text (Ask me | send plain | send both)
b) message-centric default message format setting for recipients whose preference is unknown (Send both | send HTML)
So to maintain both of these functions, the only sane value for that conglomerate pref is 'Send both' because anything else would render either recipient-centric logic or message-centric logic a NOP.

Historically, the factors and net result of Auto-Detect have not been sufficiently transparent nor controllable (e.g. Auto-Downgrade was totally invisible and uncontrollable, Bug 136502).

It's about time that we allow users to do the simple thing:
Just send all of my messages as HTML (or both), without doing any Auto-Detect guesswork. Plain and simple. Pardon. Simply rich text (aka HTML). No bells and whistles.
Iow, allow stable message-centric default setting for new compositions which bypasses any recipient-centric or other flexible logic.

Bug 136502 Comment 0 (from 2002):

Mozilla 0.9.9 seems to have a feature where it automatically downconverts email
and sends it in "text only" mode if it does not detect any formatting (such as
bold, colours etc.). There is no apparent way to disable this feature.

It would be better if the Formatting menu had an option to turn this behaviour
off and **always** send HTML (e.g. always send multipart) c.f. the default
behaviour in Netscape, Outlook, Notes, Eudora, .... - since the vast majority of
recipients are likely to have an HTML-aware client it would be nice to send HTML
so that the message appears in a proportional font, etc.

***

For Implementation:

Ideally implemented as a global default (Tools > Options > Composition...)
AND per-identity option in account settings (underneath [x] Compose messages in HTML format). The per-identity option defaults to "Use global default".

But what if the user changes identities during composition, and the default delivery format changes along with that, say from 'HTML' to 'Plaintext'?

Should we even allow 'Plaintext' as a default delivery format for HTML compositions? (Maybe not...)
+++ This bug was initially created as a clone of Bug #136502 +++

Bug 136502 Comment 168 (see also Bug 136502 Comment 44):

Implement the possibility of bypassing recipient-centric delivery format 'Auto-Detect' altogether and chose a stable default message delivery format instead, to start new compositions directly with delivery format HTML | both | plain(?).

So when you compose a new message, any of the radio options on
  Options > Delivery Format menu
will be preset at user's convenience, to avoid any guesswork about the result of Auto-Detect blackbox algorithm (which we are also seeking to make more controllable and transparent in this series of bugs).

Implementation details: Somewhere in...
Tools > Options > Composition > ... (or Send Options)
...implement the following dropdown-box:

Default message delivery format:
[Auto-Detect               v]
| *Auto-Detect*             | <- Default
| Plain text                | 
| HTML                      |
| Both plain text and HTML  |
+---------------------------+

As a global default option and perhaps per-identity (needs more thought).

I'll add more background, philosophy, and current findings to user story of this bug (see above).
User Story: (updated)
See Also: → 1727493

This is basically what bug 1727493 ended up doing, using the preference "mail.default_send_format".

Status: NEW → RESOLVED
Closed: 2 years ago
Depends on: 1727493
Resolution: --- → FIXED
See Also: 1727493
Whiteboard: [fixed by bug 1727493]
Target Milestone: --- → 101 Branch
You need to log in before you can comment on or make changes to this bug.