Implement "full send format option for all 6 cases in Send Options panel" with "Convert Prefers=Unknown to HTML Domain or Text Domain", please. This is a result of my learning in Bug 414299, Bug 584363, Bug 1204379, Bug 1210244, Bug 1215791, and Bug 136502. Some objectives of "Full send format options for all 6 cases" which I presented here. (1) multipart/alternative(Both) relevant. After HTML mail is sent to a recipient, recipient may try to forward mail as attachment to mailer which can show text mail only. In such case, "send as multipart/alternative from Tb" is useful for user, even when all recipients are HTML Domain recipients in Tb's settings. When forward, "forward as attachment" is better for readability of mail in many cases especially in business use. Please note: Tb has "HTML/Text Domain setting", but Gmail doesn't have such setting. Gmail sends multipart/alternative when HTML. "send multipart/alternative even when allHtml" is never wrong or incorrect behavior, if it's done by user's request. (2) text/plain relevant Some users actually want to use HTML composition mode for composing pure text mail. For example, h3 for heading part, italic for quoted part, normal text for body. In such case, if he sets "Text" for all cases in Send Options, he can send the HTML mail as text/plain without selecting Plain Text Only in Delivery Format menu. As you know, selecting Delivery Format menu is not difficult but is annoying for user. If not, why users won't intentionally select Delivery Format=HTML only or Both HTML and Text of Delivery Format menu even though they deeply want "text/html always in any case" or "multipart/alternative always when they want"? First one is "send format based on user's want or requirement". Second one can be called change from "auto-downgrade by Tb" to "user selected downgrade to text". If such enhancement will be implemented, current code "if(allHtml)... else if(allPlain) ..." is removed, and Send Options panel is always used, and appropriate set of send format option is chosen based on recipient type. There is no "forcing of send format by Tb". If such enhancement will be implemented, useless discussion or war like following is changed to "Meaningless" or "Nonsense". - Kill Auto-Detect or Auto-DowngradeToText - "if(allPlan&&Not-Convertible) send text/plain" is a "data loss" - "send multipart/alternative" should be used in "if(HTML recipient and Text recipient is mixed&&Convertible) send text/plain" case, or it should be optional. - Repeated saying that "Both" is needed in defafult for Prefers=Unknown is AB These are seen many times in Bug 414299, Bug 1204379, Bug 1210244, Bug 1215791, and Bug 136502. This is biggest reason why I presented "send format option for all 6 cases in panel" here. "Default for Prefers=Unknown" was borrowed from Bug 56834 which was pened on 2000-10-16. "Convert Prefers=Unknown to HTML or Text" part is a representation of following my tweet in Bug Summary of Bug 584363 in 2013. Unknown, no Address Book entry, should be treated as "prefers HTML" by Auto-Detect nowadays If lengthy statement is avoided, table of option selection for all 6 cases can be kept "Compact". I think required change in "Send Options processing logic" is not so big. Problem is: (a) new panel design and layout design. (b) implementation of the new panel. (c) implementation of back end code for the new panel UI. These are not so complicated job, but is never easy job.

For user's convenience, following is better implemented(already requested) In Ask dialog, [ ] Save this your choice in Send Options panel setting. Note: You can change it any time at Send Options panel.

Needless to say, Bug 584313(for CSS Style atribute support in Convertible check logic) should be resolved before this kind of enhancement.

A way to reduce number of required prefs. - continue to use mail.default_html_action only - change data format : assume 0=Ask, 1=Both, 2=HTML, 3=Text mail.default_html_action = "2,2,3,3,3,0" like data for 6 cases. mail.default_html_action in mailnews.js = "2,2,3,3,3,0" - If this prefs.js is used by old version of Tb, Ask is used because data is improper for old Tb. and mail.default_html_action=N is set by old Tb. So, if mail.default_html_action value is not correct for new Tb, it should be reset, and value in mailnews.js should be used, and new value shoukd be saved if non-default. If JS code, code like next can be used. var dat = prefs string in mail.default_html_action in prefs.js ; var datArray=dat.split(","); if(datArray.length==1 && datArray[0] is proper value) { // data by old version datArray=(value of mail.default_html_action in mailnews.js).split(","); datArray[datArray.length] = dat; } else if(datArray.length==6 && all datArray[nn] is proper value) { // correct data by new version Do nothing; } else { // broken data datArray=(value of mail.default_html_action in mailnews.js).split(","); } var prefsVaalue=datArray.join(",") ; // after it, new value is saved in prefs.js if different from default value in mailnews.js sooner or later

I'm not sure if WADA is really serious about this, or if it's just another strategic test balloon which he actually wants to burst so as to narrow down on the really possible solutions. Be that as it may, here's my analysis. I recommend WONTFIX for the solution proposed by this bug, both pseudo-code and UI: attachment 8678686 [details] (UI): Send options: Auto-Detect settings with 24 different combinations in 6 dropdown-boxes with plenty of descriptive text. If radio boxes, 24 radio boxes. attachment 8678546 [details] (code): 6 cases, mixing recipient scopes with message-centric convertible::plain 1) violates ux-error-prevention 2) violates ux-minimalism 3) violates ux-natural-mapping ad 1) ux-error-prevention: > Interfaces should proactively try to prevent errors from happening. Many of the 24 combinations never make sense for any type of user, because they would lead recipient-centric auto-detection ad absurdum by doing the *opposite* of what the recipient prefers. Allowing default setting like "Send Plain" when all recipients are "prefers-HTML" is nonsense and error-prone (unexpected dataloss of full HTML formatting). Let's not invite the user to get himself into trouble. Note that all combinations will be set as *default* action/format by user. I can provide details of error-prone/problematic/unwanted/unnecessary combinations on request (1 page). ad 2) ux-minimalism: > interfaces should be as simple as possible, both visually and interactively. Interfaces should avoid redundancy This is the most obvious shortcoming of exposing the full matrix of all theoretically possible auto-downgrade and auto-detect combinations: * Many possible combinations do not make sense or can produce errors and dataloss (see 1). * Auto-Downgrade is in inherently *message-centric* (for messages which are convertible::plain, which is convertible:yes in WADA's model). Iow, because the *message* looks like plaintext, *ignore/bypass/supersede* recipient-centric preferences and just send plaintext anyway (which we currently do even for somePlain && someHTML, but inconsistently not for allHTML; I propose fully message-centric approach, expand auto-downgrade scope to allHTML) * ux-minimalism: Hence, all cases involving Auto-Downgrade (convertible::plain) can be bundled into a simple, single super-switch: [x] Always send plain text (auto-downgrade) when message looks like plaintext (convertible::plain). True | False. Auto-Downgrade On | Off. It's that simple. Adding 12 mostly useless options where we can correctly get away with one while not loosing any functionality is clearly violating ux-minimalism. Note: *Auto-Downgrade* is correctly /bundled/ with recipient-centric *Auto-Detect* - because we can never auto-downgrade when user explicitly sets any other send format for the message - because we need to fall back to normal auto-detect when we the message!=convertible::plain ad 3) ux-natural-mapping: > Controls should be placed in the correct location relative to the effect that they will have. As explained in 2), the inherent design/effect of auto-downgrade is simply message-centric bypassing of any recipient-centric auto-detection. 12 theoretical combinations for a simple on/off-switch totally obfuscate that nature and confuse the user, by unnecessarily mixing message-centric with recipient-centric options. Instead, the correct UI mapping for Auto-Downgrade-Switch is a simple checkbox which must be placed *above* any auto-detect options, as seen in my proposal: XUL demo attachment 8672688 [details] screenshot attachment 8673807 [details] pseudo code Bug 1210244 Comment 202 Note that I'm fine with conflating allPlain and somePlain dropdowns of my proposal, which will significantly shrink the space needed in options panel. 'Default delivery format' can also be moved to the previous options tab where we now have the [Send options] button, to gain more space.

Comment on attachment 8678546 [details] (V1) Pseudo code for change in backend(consists of (a) "convert Unknown to HTML/Text" and (b) "use Send Options in any case") f- based on my comment 6. This is changing things in the right corner, but in the wrong way. 6 cases are not needed; 1 message-centric + 3 recipient-centric cases are sufficient. Mixing all 3 recipient-centric scopes (allPlain, allHTML, mixed) with message-centric auto-downgrade logic (ConvertibleToText) is an extremely confusing and bloated concept, which ignores the fact that (Auto-Downgrade-when-ConvertibleToText) is a simple boolean decision to just bypass recipient-centric Auto-Detection altogether (currently except allHTML scope, which we should include for consistent/transparent message-centric approach). Note that WADA's dual-pref approach of unknown==plain|html will remove any reasonable way of defaulting to unknown==both as we currently do. Imo following is not reasonable: - to set unknown==plain and allPlain->Both to get unknown==both via send options - to set unknown==html and allHTML->both to get unknown==both via send options In both cases, explicit preference for unknown is ignored and always changed to something else by send options, which is absurd.

I gave up feedback from developer. pref name was changed from "default for Unknown" to "map Unknown to HTML/Text Domain", in order to avoid repeated saying that "default of Both" is neded.

(In reply to WADA from comment #8) > Created attachment 8680931 [details] > (V2) Pseudo code for change in backend(consists of (a) "map Unknown to > HTML/Text" and (b) "use Send Options in any case") > > I gave up feedback from developer. > pref name was changed from "default for Unknown" to "map Unknown to > HTML/Text Domain", in order to avoid repeated saying that "default of Both" > is neded. Yes, "map" is probably better description of what we do, compared to "default". WADA suggests: mailnews.compose.MapUnknownToHtmlDomain (boolean). All the new prefs which we might want for this topic are about "send format" (currently known as delivery format), right? So for future easy pref management and overview by users and developers, I repeat my suggestion to have .sendformat. in the pref path. I have also laid out with detailed reason which have never been refuted yet, why I believe we need to allow mapping unknown recipient scope to "prefers-both" to keep the current default case of "both" for "unknown" without forcing users into twisted/illogical settings. So I think prefname should be something like this: mailnews.compose.sendformat.MapUnknownTo == 1 (plain) | 2 (html) | 3 (both) The values are same as for mail.default_html_action, where we also have "0 (ask)" which is not needed for unknown, because asking is only required when downgrading to plain, which is better set as unknown==plain, which will then use somePlain/allPlain send options (aka mail.default_html_action). Btw default_html_action is a pretty bad pref name which does not describe what this does, but maybe we're not here to change historical pref names.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #9) > So I think prefname should be something like this: > mailnews.compose.sendformat.MapUnknownTo == 1 (plain) | 2 (html) | 3 (both) More precisely: mailnews.compose.sendformat.MapUnknownTo == 1 (prefers-plain) | 2 (prefers-html) | 3 (prefers-both) So maybe we should also have "prefers" in pref name, to make it clear that this is NOT final send format, but just format preference which will be used by auto-detect algorithm (and usually honored, but sometimes not when prefers-plaintext recipient might require downgrading): mailnews.compose.sendformat.UnknownPrefers == 1 (prefers-plain) | 2 (prefers-html) | 3 (prefers-both)

To aceman. Top half of pseudo code is for "(a) map Prefers=Unknown to HTML Domain or Text Domain for setting allHtml/allPlsin" which can resolve almost all current bug reports for "if( all recipients is Prefers=Unknown && ConvertibleToText=Yes) send text/plain" case. Because "all recipients is Prefers=Unknown(!allHtml&&!allPlsin)" is changed to allHtml=true if pref=HTML is set, problem won't occur in this case.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #9) > WADA suggests: mailnews.compose.MapUnknownToHtmlDomain (boolean). > All the new prefs which we might want for this topic are about "send format" > (currently known as delivery format), right? No. Absolurely wrong. Please read code well. The new pref is for "mapping to HTML Domain or Text Domain to determine allHtml/allPlain in Auto-Detect of recipient type". > mailnews.compose.sendformat.MapUnknownTo == 1 (plain) | 2 (html) | 3 (both) Such pref is never needed for both (a) "map Unknown to HTML Domain or Text Domain" and (b) "use Send Options in any case". "1 (plain) | 2 (html) | 3 (both)" like one is set at Send Options panel for all cases by user. Please never repeatedly push what you want in many bugs. Please read and understand well at least "User Story" and comment #0 of this bug before comment posting,

(In adition to comment #4) Other possible methods to eliminate number of required prefs. (1) continue to use mail.default_html_action only change data format to "JSON data for simple object of send options for all cases". mail.default_html_action = JSON data for { case1 : "Text", case2 : "HTML", ... , "Ask" } mail.default_html_action in mailnews.js may not be useful, so default is better kept in progra code for Send Options panel. (2) utilize LocalStorage for complex Send Options setting. LocalStorage.addItem("case1","Text"); OptForCase6=LocalStorage.getItem("case6"); Or, LocalStorage.addItem("SendOptions",JSON data of object); SendOptionsJSONdata=LocalStorage.getItem("SendOptions"); Convert it to original JavaScript object; Data is maintained by LocalStorage and is saved in standard SQLite DB in Thunderbird/Firefox, so no need to pay attention to data loss. In Firefox, many sites such as Google already usilises LocalStorage which is succesor of Cookie. If good "URL sheme assignment" is defined in Thunderbird, "Send Options feature" can be represented as "site of TbWideOPT://Composer/SendOptions/Pref:8080" in LocalStorge system of Thunderbird.

FYI. See bug 418551 for fully utilizing LocalStorage etc. which is based on SQLite DB in Thunderbird.