Open Bug 1218156 Opened 9 years ago Updated 2 years ago

Implement "full send format option for all 6 cases in Send Options panel" with "Convert Prefers=Unknown to HTML Domain or Text Domain", with removing "any forcing send format by Tb", please

Categories

(Thunderbird :: Preferences, enhancement)

38 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: World, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Whiteboard: [Read "User Story" and comment #0 before comment posting, please])

User Story

First of all, before your comment posting, please read and understand at least this "User Story" and comment #0 well, please.

[To all comment posters]

This bug is never for discussion on a proposed solution or other possible solutions or solutions what you want.
This bug is only for analysis of "a small/minimum solution which is presented by this bug is effective or not, valid or invalid, improper or not, produces critical performance issue or not and so on".  

If such issue is not involved in the solution,
you can open separate bug for any enhancement over this simple/minimum solution.
If you have different opinion on functionality or if this simple/minimum  solution is insufficient for you or extraordinary peoples,
you can claim anything in your separate bug for any enhancement.
Please keep "comment for evaluation of the simple/minimum solution" only in this bug.

[Note on presented change]

After change, what Auto-Detect does do is:
- Auto-Detect of Convertibility of HTML => recomendation of text/plain to user,
- Auto-Detect of recipient type based on HTML/Text Domain setting and Prefers in Address Book,
- Auto-Detect of user's want on send format for each type of HTML and recipient,
With no forcing on send format to user.

There is no need of "all-in-one solution" or "release all at once".
Changes itself is absolutely independednt, so following is possible.
(1) Phase-1 : 
    Bug 584313(for CSS Style atribute support in Convertible check logic)
    (a) "convert Unknown to HTML/Text"
    =>
    Almost all current bug reports on phenomenon of "HTML mail is sent as text/plain by Tb"
    is for "if(Convertible && recipients is Prefers=Unknown only) send text/plain".
    So almost all current actual issue by auto-downgrade is resolved by
    "above two changes" + "default for Prefers=Unknown == HTML by user".
(2) Phase-2 : (b) "use Send Options in any case" over Phase-1.

[Background]

I was exhausted by Bug 1204379, Bug 1210244, Bug 1215791, and is sad by Bug 136502.
I don't want to touch UI change and code to support the UI, so I avoided referring to content/layout of Send Options panel.
But, referring to UI was needed, in order to present another possible solution in visual format, instead of in simple wordind only, to some peoples who are trying to do some changes in pretty old bug whose problem was/is not so big.

Relevant code was cleanly/clearly sorted out by implementation of bug 970118 in 2014.
Big thanks to Joshua Cranmer [:jcranmer].

[My Questions]

It looks for me that "Prefers=HTML/Text in Address Book" is (a) "send format which HTML mail creator wants to send the HTML mail to this recipient" for some users and some developers, instead of (b) "per mail address HTML Domain/Text Domain setting".
If not so, I can't imagine reason why "default of Both for Prefers=Unknown" can be requested by some users and some developers when I proposed "prefs of default for Prefers=Unknown in Address Book" which was borrowed from Bug 56834. 
From code reading, I can't imagine other definition than (b).
Was definition of "Prefers=HTML/Text in Address Book" already changed?

Attachments

(2 files, 2 obsolete files)

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.
Attachment #8678546 - Flags: feedback?(ben.bucksch)
Attachment #8678546 - Flags: feedback?(acelists)
User Story: (updated)
User Story: (updated)
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.
Attachment #8678546 - Attachment description: (V1) Psseudo code for change in backend → (V1) Psseudo code for change in backend(consists of (a) "convert Unknown to HTML/Text" and (b) "use Send Options in any case")
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
User Story: (updated)
Attachment #8678546 - Attachment description: (V1) Psseudo code for change in backend(consists of (a) "convert Unknown to HTML/Text" and (b) "use Send Options in any case") → (V1) Pseudo code for change in backend(consists of (a) "convert Unknown to HTML/Text" and (b) "use Send Options in any case")
Attachment #8678546 - Flags: feedback?(Pidgeot18)
User Story: (updated)
User Story: (updated)
Depends on: 584313
User Story: (updated)
User Story: (updated)
User Story: (updated)
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.
Attachment #8678546 - Flags: feedback-
Severity: normal → enhancement
Whiteboard: [Read "User Story" and comment #0 before comment posting, please]
Depends on: 56834
Depends on: 44494
User Story: (updated)
User Story: (updated)
Summary: Implement "full send format option for all 6 cases in Send Options panel" with "Convert Prefers=Unknown to HTML Domain or Text Domain", please → Implement "full send format option for all 6 cases in Send Options panel" with "Convert Prefers=Unknown to HTML Domain or Text Domain", with removing "any forcing send format by Tb", please
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.
Attachment #8678546 - Attachment is obsolete: true
Attachment #8678546 - Flags: feedback?(ben.bucksch)
Attachment #8678546 - Flags: feedback?(acelists)
Attachment #8678546 - Flags: feedback?(Pidgeot18)
(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)
Attachment #8680931 - Flags: feedback?(acelists)
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.
Flags: needinfo?(acelists)
Attachment #8680931 - Attachment description: (V2) Pseudo code for change in backend(consists of (a) "map Unknown to HTML/Text" and (b) "use Send Options in any case") → (V2) Pseudo code for change in backend(consists of (a) "map Unknown to HTML Domain or Text Domain" and (b) "use Send Options in any 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.
Flags: needinfo?(acelists)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: