Following phenomenon can occur in Thunderbird.
Any 'HTML mail send' falls into a Table Cell of following Table.
The 'mystery for user' occurs only in (C-1) of following Table.
When Convertible=Yes, in ordinal environment, reason why a 'HTML mail send' falls into (C-1) is that
recipient is Prefers=Unknown, because user usually keeps Prefers=Unknown in Address Book.
So, "probability of that 'mystery for user' occurs in (C-1)" is drastically changed to low,
by "interpret Prefers=Unknown as HTML or Text".
| Group | CaseID | allHtml | allPlain | Prefers=Unknown in recipients | Convertible | Current Action | Comment |
|---|---|---|---|---|---|---|---|
| allHtml | A-1 | true | false | No Unknown | Yes | nsIMsgCompSendFormat:: HTML | |
| A-2 | true | false | No Unknown | No | nsIMsgCompSendFormat:: HTML | ||
| allPlain | B-1 | false | true | No Unknown | Yes | nsIMsgCompSendFormat:: PlainText | Auto-Downgrade |
| B-2 | false | true | No Unknown | No | nsIMsgCompSendFormat:: PlainText | Auto-Downgrade Possible data loss for mail sender, because Not-Convertible (Note: Never for Text Domain recipent) | |
| Mixed (With Unknown) | C-1 | false | false | Unknown is containd in recipients | Yes | nsIMsgCompSendFormat:: PlainText | Auto-Downgrade Cause of mystery for user If Unknown is interpreted as HTML, changed to (A-1) or (D-1). If Unknown is interpreted as Text, changed to (B-1) or (D-1). So, mistery disappers. |
| C-2 | false | false | Unknown is containd in recipients | No | UseSendOptions | ||
| Mixed (No Unknown) | D-1 | false | false | No Unknown | Yes | nsIMsgCompSendFormat:: PlainText | Auto-Downgrade Can produce same phenomenon as 'mystery for user' but it's not mystery for user because reason of text/plain is understandable/acceptable for user (Text Domain reipient is requested) recipients=HTML+Text(no Unknown) is pretty rare in user's environment | D-2 | false | false | No Unknown | No | UseSendOptions |
| Group | CaseID | allHtml | allPlain | Prefers=Unknown in recipients | Convertible | Current Action | Comment |
| Note: Convertible : Yes : aConvertible==Convertible::Plain, No : aConvertible==Convertible::No | |||||||
Problem occurs in following 2 cases only.
| Group | CaseID | allHtml | allPlain | Prefers=Unknown in recipients | Convertible | Current Action | Comment |
|---|---|---|---|---|---|---|---|
| allPlain | B-2 | false | true | No Unknown | No | nsIMsgCompSendFormat:: PlainText | Auto-Downgrade Possible data loss for mail sender, because Not-Convertible (Note: Never for Text Domain recipent) |
| Simple solution | UseSendOptions always, intead of send as text/plain No need of new prefs, because this is Not-Convertible case. Current Send Options panel can be shared with (D-2)/C-2) with small wording change in panel. | ||||||
| Mixed (With Unknown) | C-1 | false | false | Unknown is containd in recipients | Yes | nsIMsgCompSendFormat:: PlainText | Auto-Downgrade Cause of mystery for user If Unknown is interpreted as HTML, changed to (A-1) or (D-1). If Unknown is interpreted as Text, changed to (B-1) or (D-1). So, mistery disappers. |
| Simple solution | Interpret Prefers=Unknown as HTML or Text according to user's prefs setting. If converted to allHtml or allPlain, problem won't occur. If converted to Mixed case, it's (D-1) HTML+Text case. Because Text Domain recipient is contained, and because Convertible case, send as text/plain is reasonaable and it's never mystery for user, because who set Text Domain is user. i.e. There is no need to change send logic for this case. | ||||||
Pretty simple solutions.
Because phenomenon when Auto-Detect is used,
and because relevant conditions is A_function(allHtml, allPlain) and aConvertible,
if a condition is changed from true to false, mystery disappears.
So, many workarouds are already well known.
And some solutions are requested.
| Cause of phenomenon | Solution | Description of solution |
|---|---|---|
| Auto-Detect is used(forcced) | Don't use Auto-Detect | (Official-1) Delivery Format=HTML Only or Both |
| Option not to use Auto-Detect | (Enhancement-1) Bug 136502 | |
| !allHtml && !allPlain | Get allHtml=true or allPlain=true | (Official-2) Correctly set Prefers=HTML or Prefers=Text in Address Book |
| aConvertible is Yes | Force aConvertible=No by tag, color setting | (Workaround-1) background color=#FEFEFE, text color=#FFFFFF etc., use <B></B>, <FONT> etc. |
| Fake aConvertible=No, without calling Tb's functiom | (Workaround-2) Install 'Always HTML' addon | |
| aConvertible=No from Tb's function | (Enhancement-2) Bug 414299 (tag) | |
| (Enhancement-3) Bug 584313 (CSS Style) |
Any HTML falls into a Table Cell of following Table.
If Not-Convertible is returned to "tag which has style attribute",
probability of that 'mystery for user' occurs is drastically changed to low in 'CSS Style is used' cases of Simple HTML cases.
Type-1-1/Type-2-1 is current design/implementation.
Bug 414299 is for Type-2-1.
Bug 584313 is for Type-1-2/Type-2-2.
Repeated "severe/critical/massive format/data loss" seems "CSS data is lost in Type-1-2 case of the Table".
| What kind of simple HTML can produce Convertible=Yes? | |||
|---|---|---|---|
| HTML type | used HTML tag | No CSS | CSS Style is used |
| Simple HTML-A (Type-1) | Body Text, <P>, <PRE> only | Type-1-1 O | Type-1-2 O |
| Simple HTML-B (Type-2) | Type-1 + <TT>, <A> with link text==link url | Type-2-1 O | Type-2-2 O |
| Complex HTML (Type-3) | Tag for format is used | Type-3-1 X | Type-3-2 X |
| Minimum "Simple HTML" example:
<html><body bgcolor="#FFFFFF" text="#000000">
Type text here </body></html> Minimum "Complex HTML" example:
<html><body bgcolor="#FEFEFE" text="#000000">
Type text here </body></html> | |||