Closed Bug 1202227 Opened 6 years ago Closed 4 years ago

Text alignment gets discarded from HTML compositions when sending (Delivery Format: Auto-Detect; recipients prefer: HTML(!) & Unknown; Unknown)

Categories

(MailNews Core :: Composition, defect)

defect
Not set
normal

Tracking

(firefox43 affected)

RESOLVED DUPLICATE of bug 1384361
Tracking Status
firefox43 --- affected

People

(Reporter: thomas8, Unassigned)

References

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

Details

(4 keywords, Whiteboard: [ux-wysiwyg])

User Story

User composes in HTML mode and applies all sorts of HTML formatting, here: explicit text alignments left, right, center, justify. Otherwise <tt>, <pre>, links, CSS-styles etc. Upon sending (saving/closing/reopening?), delivery format default setting (Auto-Detect) unexpectedly decides to dump all such formatting without notice, and sends a garbled plaintext message. Massive violation of ux-wysiwyg. Cunning, too, because unless user checks the sent msg or gets feedback from recipients, he might never notice the dataloss of formatting. Plus the current misdesign makes it so that even setting all related per-account, per-recipient and send options to "HTML" will NOT prevent Auto-Detect's arrogant and predatory behaviour.

Workarounds: Known methods to skip hard-to-disable "feature" of "Auto-downgrade to Text" (when sending) of message composed in HTML by user all the way:
(a) add <b></b> in HTML signature, set text color to #000001, set background color to #FFFFFE, etc.
    These are pretty important for gMsgCompose.bodyConvertible(), so, if such attribute is used in HTML mail, gMsgCompose.bodyConvertible() doesn't do "Autodowngrade to Text" fortunately.
(b) Install "AlwaysHTML" addon: https://addons.mozilla.org/de/thunderbird/addon/always-html/
    AlwaysHTML addon won't call gMsgCompose.bodyConvertible(), so "Autodowngrade to Text" is skipped.
+++ This bug was initially created as a clone of Bug #414299 +++

STR:

1) Compose HTML message to recipient who "prefers to receive messsages formatted as: Unknown (default)". Set "when one or more recipients can't have HTML" to anything which is NOT "just send plaintext" (default: Plaintext AND HTML), to indicate your preference for HTML delivery format.

2) Format some text using the text alignment button from composition toolbar (do not use any other formatting):
---
Left
                    Right

        Center

Justified asdf asdfa sdfa
asdfasdf  asdfasfd  uasdf
---
Real-life example:

                 Someplace, 6th Sept. 2015

Dear customer,

we'd like to invite you to our

     Fund Raising Dinner

All  proceeds  will  go to charity.
We hope  to  welcome  you  to  this
extraordinary event.
---
3) Send (to outbox for testing purposes, Ctrl+Shift+Enter)
4) Look at sent message

Actual result

* All explicit text alignment has been silently dumped by Auto-Detect aka Auto-Degrade.
---
Left
Right

Center

Justified asdf asdfa sdfa
asdfasdf asdfasfd uasdf
---
Someplace, 6th Sept. 2015

Dear customer,

we'd like to invite you to our

Fund Raising Dinner

All proceeds will go to charity.
We hope to welcome you to this
extraordinary event.
---

Expected result:

* We must never dump explicit formatting after the fact, with default HTML settings
- ux-wysiwyg
- ux-control
- ux-error-prevention
- ux-consistency
For details, see Bug 414299 Comment 133.
* Send (plaintext+)HTML as set in options. Should not degrade to plaintext unless (PERHAPS when) ALL recipients have preference for plaintext; in that case, probably prompt (or act according to existing setting).
* Should regard "Unknown" preference as capable of HTML
Summary: Text alignment from gets discarded from HTML compositions when sending (Delivery Format: Auto-Detect; recipient prefers: Unknown) → Text alignment gets discarded from HTML compositions when sending (Delivery Format: Auto-Detect; recipient prefers: Unknown)
> Bug Summary part-A : Text alignment gets discarded from HTML (snip)

What is difference from bug 414299 and many variants of it(see dependency tree for bug 889315)
(these are for issue of AutoDowngradeToText regardless of Preference in Address Book) 

> Bug Summary part-B : Delivery Format: Auto-Detect; recipient prefers: Unknown

What is difference from bug 584363??
(that bug is is for case that AutoDowngradeToText is bypassed and Send Option for HTML message is applied)
Do you see your problem with "Ask in Send option for message which is being sent as HTML"?
Hi WADA, the problem is some developers apparently do not understand the nature/gravity/amount of the formatting dataloss we are talking about, and maybe they think dataloss of formatting is no problem. So I think the only way is to file all the symptoms seperately and discuss them one by one. The symptoms are different. The root cause is always the same: Auto-degrade sucks and destroys consequential formatting (part-A). And Auto-detect currently fails: if combined with "unknown", even recipients explicitly preferring HTML will receive degraded plaintext instead (part-B).

Send options (pref mail.default_html_action) currently have 4 choices:
"When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML" (prefers unknown or plaintext in AB card):
0 ask user which delivery format | 1 downgrade silently to plaintext | 2 send HTML-only | 3 send HTML+Plaintext.

The problem is, as you correctly analysed, that we downgrade *before* detecting the recipient type, so for cases where TB assumes it can do "lossless conversion" (what a joke looking at my testcases in Bug 414299!!!), we never get to observing the pref, because downgrade-to-plaintext has already been decided *before* looking at the actual recipient preferences, although there's substantial formatting and some recipients might even explicitly prefer HTML.

This bug is reporting another symptom to show that so-called "lossless conversion" is NOT lossless. Just dumping deliberate text alignment like centered, right, justified is dataloss of formatting. Full stop. I compose in HTML, I set the pref to "ask me" or anything with HTML, I can even set recipients to "prefers HTML", and then ultimately, if there's just a single other recipient who happens to be "unknown", even the HTML recipients will receive degraded plaintext message. No questions asked, no HTML sent. It's insane. And I can't believe that others are unable to see the arrogance and wrongness of this dataloss behaviour against users will. Even if we allow users to pre-select or remember their preferred format, (optional) Auto-Detect will still do the wrong thing. "Unknown" is NOT the same as "prefers plaintext", especially if combined with explicit "prefers HTML" recipients! So who are we to mess with the user's message and ignoring his explicit preferences?? Really, the stupid arrogance of this behaviour is unbelievable. "Unknown" means "we don't know if user prefers HTML or plaintext"; if there's even the slightest hint of formatting (ux-wysiwyg), and definitely if there are other recipients who prefer HTML, then we MUST send HTML (plus plaintext if needed and wanted). Beyond that, I also think it is safe these days to err in favor of "Unknown"=="can handle HTML" which is true for most recipients and MUAs these days. If we have serious doubts, we can even send both formats, or just observe the damn pref. We must stop ignoring our users and their preferences.
(In reply to Thomas D. from comment #2)
> And Auto-detect
> currently fails: if combined with "unknown", even recipients explicitly
> preferring HTML will receive degraded plaintext instead (part-B).

I forgot the worst failure: Let's say I've got the pref set to "Ask me". So user has explicitly instructed TB: "When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML" (prefers unknown or plaintext in AB card): ASK me what to do (to avoid silent formatting dataloss and give user a choice). Due to wrong auto-detect algorithm, even if user spends 3 hours to compose a full-fledged HTML message with inline images, bold, alignment, styles etc., and if user then happens to choose *only* "prefers plaintext" recipients, ALL HTML formatting will be dumped WITHOUT ANY WARNING. And it's NOT recoverable either, it's just gone for good. It's madness. It's only that it doesn't happen so often these days because nobody sets recipients to "prefers plaintext" anymore. But still, such unexpected, silent dataloss must never happen in a serious application. If you change a single character in your composition, we ask when user closes the window (and we don't offer a way of turning that question of, for obvious reasons). If you are going to lose all your HTML formatting, we just discard it silently without asking, even if user demands to be asked. It's madness. Gross violation of UX principles (ux-error-prevention).
It's a complex thing and we need to test all the different scenarios (levels of formatting, special cases of formatting, mixed types of recipients etc.) to see where we go wrong. Our users have filed countless bugs to complain about the whole inconsistency, and we have ignored them for decades. It's sickening. I actually feel like stopping to contribute to TB altogether, if we are not able to agree on fundamental failures and obvious violations of UX principles like this. But I think many people, even developers, do NOT fully understand all the details. And I admit it has taken me very long, perhaps years, to understand all the weirdness of auto-detect and related delivery format settings. Sometimes I still get confused (then what about the poor average user who centers some text and it's suddenly not centered when he sends it?). Looking at that code can give you a true headache. Code and performance is the other side of this: We have very complex and performance-heavy code for little gain. For many everyday scenarios, say for all messages with a single bold character, the whole body-parsing for "lossless" conversion is completely superfluous, just a waste of time, and high maintenance burden. And what is the ultimate goal of auto-degrade?? I mean, if users really want to send plaintext, why don't they just use the plaintext editor instead??? Why compose in HTML and then have your formatting, even inline images randomly and inconsistently/unpredictably dumped away upon sending?? And WHY does TB still prefer plaintext these days for users who explicitly compose in HTML??? For a decrease of 20 KB in message size? That's nothing against the annoyance of corrupted messages.
Thomas, I hope the devs start listening, I'd hate to see you get so frustrated that you leave TB development altogether, you do a lot for the project.

Devs? Please stop knee-jerk dismissing this/these issues, and please try to open your mind and listen.
Is there any other worthwhile MUA out there who degrades explicit HTML messages into plaintext before sending? Worse, without giving the user a choice??

Auto-*degrade* must go (because we can never get that right), but perhaps auto-*detect* can be improved to do the right thing (decide on the best delivery format for a given set of recipients, and take the lowest non-datalossy denominator.

a) If we could agree to just send HTML OR HTML+plaintext for "unknown" cases, it becomes very simple and straightforward (draft for better auto-detect decision-making for delivery format):

recipients of type -> delivery format

all plaintext -> plaintext (and follow default_html_action pref, i.e. NO silent, hardcoded *full* dataloss downgrading like now, unless explicitly set or confirmed by user).
all html      -> html
all unknown         -> html(+plaintext)
unknown + plaintext -> html+plaintext
unknown + html      -> html(+plaintext)

b) Otherwise, if we want to give user more control and avoid sending "both" by default, we'd probably need a new pref to let the user decide if "unknown" should prefer html, plaintext, or both? (needs more thought)

all plaintext -> plaintext (and follow default_html_action pref, i.e. NO silent, hardcoded *full* dataloss downgrading like now, unless explicitly set or confirmed by user).
all html      -> html
all unknown   -> HTML OR Plaintext OR both OR ASK (per new pref, PLUS follow old default_html_action pref for cases of downgrading to plaintext)
unknown + plaintext -> if unknown==plaintext(new pref): plaintext (plus default_html_action pref for cases of downgrading to plaintext, which might add or substitute by html format, or ask);
                       if unknown==html|both(new pref): html+plaintext
unknown + html -> if unknown==plaintext|both(new pref): html+plaintext;
                  if unknown==html(new pref):           html

I wish we could have an XUL demo of all the combinations as they are now and how we could improve it.
(In reply to Charles from comment #5)
> Thomas, I hope the devs start listening, I'd hate to see you get so
> frustrated that you leave TB development altogether, you do a lot for the
> project.
> 
> Devs? Please stop knee-jerk dismissing this/these issues, and please try to
> open your mind and listen.

+1. I'm really amazed how all of my elaborate, painstaking and long-term analysis of current problems, ux-failures etc., across a number of related bugs linked up in 'my' meta bug 889315, can just get dismissed with a two-liner "ui-review" (Bug 1202276 Comment 7) which is also factually wrong. I bet that neither the current behaviour nor the consequences of my patch there have been correctly understood. It's damn hard to understand and predict the actual outcome of the following factors, all of which finally determine the delivery format of your particular HTML message:

1) per-message delivery format selector (HTML|plaintext|both|Auto-detect) - wow, this one actually works for all cases except auto-detect!
2) Auto-Degrade & Auto-Detect internal conglomerate algorithm (hardcoded, hidden delivery format decisions that override almost everything just as they please! Strong bias for plaintext, wanton/random destruction of consequential HTML formatting especially for "unknown" and "prefers-plaintext", but also for "prefers-html" (whenever combined with "unknown" recipients)!)
3) per-account HTML composition pref (HTML|plaintext) - which gets randomly ignored if HTML
4) per-recipient delivery format pref (HTML|plaintext|unknown) - which gets randomly ignored if HTML or "unknown"
5) default_html_action pref (Ask|HTML|plaintext|both) which however is influenced and sometimes defeated by Auto-Degrade & Auto-Detect conglomerate algorithm; pretends to apply when recipients prefer "unknown" or "plaintext" but does NOT rule all-plaintext case, only sometimes rules cases involving "unknown", depending on specific message formatting vs. Auto-degrade, etc. etc...
6) which type of HTML formatting and how and where and when you apply it (yes, it makes a big difference wrt Auto-Degrade - styles on <div> survive, styles on <a href> die, <b> survives, <div align=center> dies, <div style="text-align:center"> survives. UX-consistency!?? Even *when* you apply your HTML formatting matters: At least in the past we also had cases where when you saved and reopened your drafts, formatting was lost and you could just continue in plaintext editor. We still have that now because any message which gets degraded by auto-degrade can NEVER ever be "edited as new" as HTML in TB again (from sent folder or after receiving)...

I really want to see that person who can correctly and immediately predict the delivery format outcome for all of their various particular formatted messages and their particular set of recipients with "delivery-format: auto-detect"... Can you???

And does anyone believe that if we start to change anything in this complex system, a two-liner is likely to make a sufficient ui-review? Think again, please. I have done a LOT of thinking on this. I'm not saying I'm done with thinking, I'm not saying I know it all, but I suspect that there are not too many people out there who have a similar overview like WADA and myself, both in terms of which problems our users have reported, and in terms of the behaviour discussed here. I rest my case. This is extremely tiring, especially when all analysis, discussion, and real user problems seen gets shot down with a premature ui-r- and alternative solutions which solve nothing at all (albeit they improve things). But yes, you need to understand the whole damn system to know why they don't.

TLDR;? Auto-Degrade & Auto-Detect internal conglomerate algorithm SUCKS (while Auto-*detect* could be good if we fixed it). More techically, it's a massive violation of UX-wysiwyg, UX-error-prevention, UX-control, UX-consistency, you name it. For some details, see my Bug 414299 Comment 133.

Most of our users just hate it, that's why there's 12,000 downloads of "Always HTML" add-on which will NOT make "always HTML", as it only disables auto-degrade and leaves auto-detect untouched. And some will never know they hate it, because TB destroys your formatting silently so in most everyday cases you need your recipients to show up and tell you about your broken format (how embarassing!), or to revisit and examine that message in your sent folder. And we will never know how much people hate it, or how many, e.g. because we can't tell how many users are intentionally or inadvertently using the known workaround of having that particular bit of HTML formatting in your message which Auto-degrade by its divine grace decides to preserve. Don't you ever think TB should just do what YOU want and define as a user. TB will do what some plaintext-loving developers once upon a time decided it SHOULD do for you...
I can't understand why many similar bug opens is needed and repeated complaints of "data loss" is needed.
As we already know, code by "Always HTML" addon surely prevents "Auto & silent downgrade to Text even though user intentionally composed mail in HTML mode".
Needed request is following, isn't it?
- Stop to force "Auto&silent downgrade to Text even though user intentionally composed mail in HTML mode". 
- Include code of "Always HTML" as "standard feature of Thunderbird", 
  and create option for ”current code" or "Always HTML code".

Once "Always HTML code" effectively works, all options in "Send Options/"When sending messages in HTML format..." works as expected/as currently designed/as currently implemented when a mail is composed in HTML mode by user.
FYI.
"Send in Text even when composed in HTML" is required feature, because some companies still accepts Text mail only.
This is reason why "preference=Plain Text in address book", "Send Options/"When sending messages in HTML format...", "Text domain / HTML domain setting" is implemented.
(In reply to WADA from comment #9)
> FYI.
> "Send in Text even when composed in HTML" is required feature, because some
> companies still accepts Text mail only.

It is true that some recipients prefer/ require plain text. But it does not mean we should degrade mails without even asking. TB should just display a warning (best when recipient was selected, usually no content yet) and let user to switch to plain text editor. This is the proper way. User will know this will be sent as plain text, user would do formatting, if required, in a plain text way.

Instead TB just allow You to edit pretty html, then without asking trashes it. F@#g annoying.
(In reply to WADA from comment #9)
> FYI.
> "Send in Text even when composed in HTML" is required feature, because some
> companies still accepts Text mail only.

That sounds wrong as it stands but maybe you mean it right, WADA. 
1st, if user knows in advance that all recipients want text-only, he should use composition mode "plaintext". It does not make sense to compose in HTML and then wait for surprises how TB is going to downgrade your message correctly (or not).

2nd, I think even for recipients of type "prefers-plaintext", multipart/alternative with text/html and text/plain parts is OK, because then they will just readd the plaintext part, right?
So technically, message with only one part of plaintext-f=f is NEVER required.

3rd, we as a matter of courtesy, when user starts composing HTML and we find that *all* recipients are plaintext, the right thing to do would be, as Arivald says in comment 10, to warn early and NOT just when the message finally gets sent and it's too late. Inline notification bar would be good to not disturb the composition. Otherwise in current design we should act according to default_html_action pref, so user can decide in advance how to handle such cases. The pref defaults to html+plaintext, so that's covered correctly. Only that we ignore the pref because the algorithm for allPlain decides to bypass the pref and just sent plaintext without warning, dumping FULL HTML formatting (inline images etc.) without any warning if the pref says "Ask me!!!". That's a bold bug.

4th, if you actually mean there are recipients who require single plaintext+f=f part ONLY (cannot handle multipart/alternative!?), then that's clearly an edge case which should be really rare these days.
User can use the above methods to control it if we fix these methods to actually work predictable and controllable like designed, and not secretly decide otherwise as we do now. Otherwise, just use plaintext editor, and don't mix recipients for that case. Alternatively, use per-message setting of delivery-format: plaintext only. That's an exceptional case so we can expect users to take care of it themselves by manual intervention. But please leave the default cases alone.

In fact I would probably argue that cases of major dataloss should ALWAYS be warned against in some way, we shouldn't allow user to switch off warning (even inline notification warning maybe).

5th. BUT, the main problem is when sending messages to recipients of type "unknown", mixed with recipients who "prefer-plaintext" or "prefer-HTML". That's a bad failure at the moment because a single plaintext or even unknown recipient can spoil it for all the other recipients and cause downgrading to text-ONLY. Which is just nonsense and should never happen with auto-detect.

6th. Bottom line: For auto-detect, "Send in Text[-only] even when composed in HTML" must NEVER be default setting for any case. It might be useful for some edgecases, so we offer it from the pref which is enough (but that pref should not downgrade "unknown" unless explicitly requested). Otherwise, use alternative methods described above.

> This is reason why "preference=Plain Text in address book", "Send
> Options/"When sending messages in HTML format...", "Text domain / HTML
> domain setting" is implemented.

Let's be careful and avoid misunderstandings. "Prefers plaintext" does NOT meant that this person cannot handle multipart/alternative or we shouldn't send that. It just means that this recipient prefers/needs one text part among the different parts. So for mixed recipients, we'll add the text/plain part to the usual text/html part. HTML is definitely the default format these days (and current Thunderbird reflects that on the surface, but the internals work otherwise!!!), another reason why "prefer-plaintext at all costs" by auto-degrade and detect is so badly annoying.
(In reply to Arivald from comment #10)
> (In reply to WADA from comment #9)
> > FYI.
> > "Send in Text even when composed in HTML" is required feature, because some
> > companies still accepts Text mail only.
> 
> It is true that some recipients prefer/ require plain text. But it does not
> mean we should degrade mails without even asking. TB should just display a
> warning (best when recipient was selected, usually no content yet) and let
> user to switch to plain text editor. This is the proper way. User will know
> this will be sent as plain text, user would do formatting, if required, in a
> plain text way.

Yes, such new ideas make a LOT of sense. Even inline notification bar. And, well, the damn switch between HTML and plaintext which has been requested a million times (but it's a can of worms which I would hesitate to open). We need to stop thinking from this rotten dinosaur algorithm, and allow fresh thoughts which really address these problems in a transparent way, not the hidden and cunning agendas to force plaintext down everyone's throat as we have them now.

> Instead TB just allow You to edit pretty html, then without asking trashes
> it. F@#g annoying.

+1. Technically, massive dataloss and violation of ux-error-prevention.
(In reply to WADA from comment #8)
> I can't understand why many similar bug opens is needed and repeated
> complaints of "data loss" is needed.

WADA, I don't see your problem. The dataloss is real. I'll happily close all these bugs when they have been addressed. Until then, I consider them necessary pieces to make others understand and act on the big puzzle. Unrequested, silent, inconsistent auto-degrade is still very much alive and you never know which idiot will crawl out of his corner to defend the destruction of every single tag which he claims to be "inconsequential". I DO think text-align is consequential formatting, hence this bug. So until we've actually killed the predatory dinosaur, every offence must be tracked. Remember, the author and master-defender of auto-degrade claims (even in the code), that his algorithm is "lossless conversion". Remember that he also insists on that rubbish that some types of formatting can be discarded just because he believes he can decide that unilaterally while ignoring the legitimate interests and intentions of our users. Remember also that so far we have not heard a single word from that person to admit or apologize for the massive dataloss and confusion caused by his f@$&%g ideosyncratic algorithm, and we have never seen the slightest indication of cooperation to understand the issues and improve them. In most cases, he has neither listened nor responded to the facts. Against such stubborn arrogance and plain lies, I see no other way except exposing the truth of dataloss for every single symptom that we can find (and <div text-align: center> is structurally different from the other full-tag losses like <tt>, <pre> wrt the internals of auto-degrade). As a de-facto member of the TB UX team, I feel obliged to stand up against unwarranted dataloss on behalf of our users, and I reserve the right to continue raising these issues until they have been addressed. FYI, i have tried for a long time to bundle related problems in bug 414299 and find a comprehensive solution there, and you'll surely remember how somebody has deliberately and maliciously thwarted any attempt of adjusting the scope of that bug to the actual discusion which happened there. So again it's sometimes better to start out in clean bugs in a smaller and more friendly environment.

> As we already know, code by "Always HTML" addon surely prevents "Auto &
> silent downgrade to Text even though user intentionally composed mail in
> HTML mode".

You and I know it, WADA, but what about other devs? Someties it looks like some of them don't know the details of the auto-degrade-and-detect algorithm. But the devil is clearly in the detail.

> Needed request is following, isn't it?
> - Stop to force "Auto&silent downgrade to Text even though user
> intentionally composed mail in HTML mode". 

+1 (which needs *more* than just the Always HTML approach of isConvertible.No)

> - Include code of "Always HTML" as "standard feature of Thunderbird", 

+1 

>   and create option for ”current code" or "Always HTML code".

I doubt that we really want to maintain that predatory option in its curren't shape. Perhaps if we shift it to some other place in the code chain so that it can't to much damage any more. But the degrade-algorithm itself is so flawed that it's pretty much beyond repair. And if you repair it properly, it will be useless. Auto-degrade is a flawed idea to begin with. It was introduced maybe to avoid asking questions too often, but the times of asking to enforce plaintext are over and will now just affect a tiny fraction of users or scenarios.

> Once "Always HTML code" effectively works, all options in "Send
> Options/"When sending messages in HTML format..." works as expected/as
> currently designed/as currently implemented when a mail is composed in HTML
> mode by user.

No they won't work as expected. Look for allPlain in code which also causes massive unprotected dataloss just on its own, even after including the addon patch. That code will still bypass the pref e.g. for cases where all recipients prefer plaintext. You haven't tried my example that even inline images get silently discarded for allPlain with pref set to ASK?
As far as mail composed in HTML mode is being sent as HTML, Send Options/"When mail is sent in HTML..." is normally applied.
Quick look of behavior of the Send Options:
 If all recipients are Preference=HTML, send as HTML,
 Else if all recipients are Preference=Text, send as Text
 (text/plain part only in multipart/alternative if both Rich Text & Plain Text are sent),
 Else(mixed preference, or "Unknown" or "Undefinded in AddresBook" is involved), Ask to user :
   "Asking any time in this case" is annoying for some users, so, default in this case can be set.
   if "HTML is requested in Send Options, send as HTML without asking,
   and if Text is requested in Send Options, send as HTML without asking.
   This is same as "reply HTML" or "reply Text" at dialog when Ask is set.  
This is never same as AutoDowngradeToText. It's "Text conversion from HTML" requested by user via Send Options settings.

Is above wrong? (I thought Unknwon==Plain Text is not applied any more. I thought Unknown==Unknown is applied.) 

"Preference=Text in Address Book" is request of "send in Plain Text always because he accepts Text mail only", isn't it? (can be called "per mail address HTML or Text domain")

As for "Preference=Unknown in AddressBook case", I think phenomenon is same as "intentional Delivery Format=Plain Text Only case". I believe that repeated complaints of "data loss" is useless. I believe reasonable request is one like next.
  If mail which was composed in HTML is sent as Plain Text, image is removed.
  So, mail is better sent as multipart/mixed{ text/plain, image/jpeg } if embed image is involved.
Please surely separate problem of "AutoDowngradeToText which Tb currently forces regardless of user's option setting or user's intent", problem in "Send Options, HTML domain, Text Domain", problem in Delivery format=Plain Text Only for mail composed in HTML".

For "Always HTML code should be optional" :
  Following is possible with current code:
    User always compose mail in HTML mode.
    (a) If user wants to send in Text, don't use use color="#000001", <B></B> etc.
    (b) If user wants to send in HTML, use color="#000001", <B></B> etc.
        Note: this is "Official way to force HTML without AutoDowngradeToText", because so coded.
I think (a) is pretty convenient for user like me, because colorful HTML mode can be used any time.
If "Always HTML code" is not optional, Tb users looses convenient (a) :-)
Please read bug 584363 comment #11 for (a) "Preference=HTML without any format, Ask in Send Options" case and (b) "Preference=Unknown with color=#ffff00, Ask in Send Options" case.
(a) is for check of AutoDowngradeToText case.
(b) is for check of Send Options/"When mail is sent in HTML..." case.
That was check result in 2012, but I think implementation is not so different in recent Thunderbird releases.
(In reply to WADA from comment #14)
> As far as mail composed in HTML mode is being sent as HTML, Send
> Options/"When mail is sent in HTML..." is normally applied.
> Quick look of behavior of the Send Options:
>  If all recipients are Preference=HTML, send as HTML,
>  Else if all recipients are Preference=Text, send as Text
>  (text/plain part only in multipart/alternative if both Rich Text & Plain
> Text are sent),
>  Else(mixed preference, or "Unknown" or "Undefinded in AddresBook" is
> involved), Ask to user :
>    "Asking any time in this case" is annoying for some users, so, default in
> this case can be set.
>    if "HTML is requested in Send Options, send as HTML without asking,
>    and if Text is requested in Send Options, send as HTML without asking.
>    This is same as "reply HTML" or "reply Text" at dialog when Ask is set.  
> This is never same as AutoDowngradeToText. It's "Text conversion from HTML"
> requested by user via Send Options settings.
> 
> Is above wrong? (I thought Unknwon==Plain Text is not applied any more. I
> thought Unknown==Unknown is applied.) 

Yes, it is. Still does not fix the real problem: if mail have to be sent plain text, it have to be edited in plain text editor. 

First, the HTML to plain conversion is not perfect, it can mess things.
Second, if user uses HTML editor, it is kind of promise to sent as HTML. It is wrong to break this promise. Instead, TB should propose to change to plain text, as soon as it detect that mail shouldn't/couldn't be send as HTML. During switch it should apply current HTML-to-plain conversion, then user will have a chance to fix any errors and apply plain text formatting.

The "as soon as it detect", sometime would mean just from start (like for news, or accounts marked as non-HTML), or just after setting recipient who does not allow plain text.

It is simple as that. Just allow user to switch editor to plain text, so user will be able to compose a plain message.
All other preferences to select between HTML and plain are just a secondary problem.

It works for me, for example for usenet, editor automatically starts in plain text mode. 
For mail, if I know I need plain, I start plain text editor right away, instead of stating HTML one, and believing in "conversion".


BTW I know it is not exactly related to the subject of this bug, but this is the real problem. Not the conversion problems, not the preferences to select HMTL/plain, but fact that we allow user to edit HTML, when we know message will be send plain, and our HTML to plain conversion, that does not allow user to fix any error.


Thomas, can You evaluate this kind of change? It's implications on current logic and UI.
In my opinion it will greatly simplify things.

I think I could make a proof of concept extension for this, althoug there is limit on what can be done from the JS.
Sigh...

(In reply to WADA from comment #14)
> As far as mail composed in HTML mode is being sent as HTML, Send
> Options/"When mail is sent in HTML..." is normally applied.

Send options are only correctly applied if Auto-Degrade is happy to apply them. If Auto-Degrade declares that "this mail has no formatting" (isConvertible==plain), even though there is consequential formatting, then HTML mail is not sent for cases where recipients are unknown, undefined, html & unknown, html & undefined, or html & plain. Only allHTML works.

> Quick look of behavior of the Send Options:
>  If all recipients are Preference=HTML, send as HTML,
>  Else if all recipients are Preference=Text, send as Text
>  (text/plain part only in multipart/alternative if both Rich Text & Plain
> Text are sent),

I don't understand the if.
Current behaviouor is
allPlain -> Plain (without ever asking, even for fully formatted HTML with images)

In that case, send option is unexpectedly ignored.
Send option says:

When sending messages in HTML format (true for inline images, definitely)
and one or more recipients are not listed as being able to receive HTML (true, all listed to prefer plain)
then execute whichever send option I prefer (ASK | plain | html | plain+html) (not executed for allPlain)

So all conditions of send options apply but the preferences is NOT executed, which is clearly a bug in auto-Detect.


>  Else(mixed preference, or "Unknown" or "Undefinded in AddresBook" is
> involved), Ask to user :
>    "Asking any time in this case" is annoying for some users, so, default in
> this case can be set.

As explained above, auto-degrade decides beforehand to ignore the pref or not.

>    if "HTML is requested in Send Options, send as HTML without asking,
>    and if Text is requested in Send Options, send as HTML without asking.
>    This is same as "reply HTML" or "reply Text" at dialog when Ask is set.  
> This is never same as AutoDowngradeToText. It's "Text conversion from HTML"
> requested by user via Send Options settings.
> 
> Is above wrong? (I thought Unknwon==Plain Text is not applied any more. I
> thought Unknown==Unknown is applied.)

It's not applied for all formatting which auto-degrade wrongly considers "lossless".
A lot of formatting including stylesheets on all Tags which auto-degrade wrongly considers "lossless".

The problem is, Auto-Degrade was designed to avoid asking too often when ASK was still the default. But ASK is no longer the default, but Auto-Degrade is still as predatory as before.

> "Preference=Text in Address Book" is request of "send in Plain Text always
> because he accepts Text mail only", isn't it? (can be called "per mail
> address HTML or Text domain")

Well, NO. prefers=plain means we need to include plaintext part in multipart/alternative. It does NOT mean that we should spoil *any* formatting for concurrent HTML or unknown or undefined recipients who happen to be in the same mail with a prefers-plain-recipient.

> As for "Preference=Unknown in AddressBook case", I think phenomenon is same
> as "intentional Delivery Format=Plain Text Only case".

Current design: Unknown == prefers-plain (for all formatting which isConvertible wrongly considers lossless, but how can dropping of background colors, alignment, classes and styles ever be lossless?). WHY???
This is wrong. Unknown or undefined MUST err in favor of HTML today, for two reasons:
- HTML is default standard for the entire WWW, including email, and accepted by most MUAs
- UX-WYSIWYG, UX-error-prevention: we must send message as seen on screen (unless user explicitly consented to "randomly dump my formatting").

And again, I am refusing to understand why anyone would want to compose in HTML (even possibly include inline images), and would then want all that formatting to be wiped away upon sending for many unpredictable cases. Why not compose in plaintext editor straight away??

> I believe that
> repeated complaints of "data loss" is useless.

Silent, unrequested dataloss of formatting is exactly what our users experience, as my testcases on bug 414299 show quite drastically.

The net result of auto-degrade-and-detect is this:
TB prefers plaintext and tries to discard HTML at all costs (some costs clearly too high).
TB ignores prefers-plaintext for many cases.

That's the other side of the coin:
Why is it that if I set recipients explicitly to "prefers-HTML", and if they happen to mix with "prefers-plain", prefers-unknown, or undefined, then "prefers-HTML" is just ignored!???
So we "respect" prefers-plain, but (for many substantial cases), we ignore prefers-html?
It's just nonsense from beginning to end.
It's also unpredictable.

We must make it so that preserving HTML formatting becomes the norm, not the exception. For the minority of users who don't want that, please use plaintext editor, or set delivery-format=plain manually.
Maybe we can introduce a hack that when you put something special in your body text, say "~~#!?~~", we will force-downgrade the message to plaintext for all recipients. Sounds stupid? Not more stupid than forcing users to put <b></b> into their signatures just to preserve their deliberate and explicit HTML formatting. Btw I do NOT agree with Joshua's hypothesis that we could perhaps find out which formatting has been intentionally applied or not. It doesn't matter if I manually changed the formatting, it only matters that the formatting is there on screen (ux-wysiwyg). We have no way of telling apart safely which formatting should be preserved or not.

> I believe reasonable request
> is one like next.
>   If mail which was composed in HTML is sent as Plain Text, image is removed.
>   So, mail is better sent as multipart/mixed{ text/plain, image/jpeg } if
> embed image is involved.

That could be a minimal hack fix for the allPlain recipients case, but never silently unless user requested Send-option "plain", which in the current workflow then violates the interests of HTML recipients.
Maybe if we change auto-detect to add html part when there are concurrent html recipients.
I offered some tentative suggestions for better auto-detection in Bug 1202227 Comment 6.

> Please surely separate problem of "AutoDowngradeToText which Tb currently
> forces regardless of user's option setting or user's intent", problem in
> "Send Options, HTML domain, Text Domain", problem in Delivery format=Plain
> Text Only for mail composed in HTML".

Yes, you are right. However, these are currently intertwined in a way that no user can easily predict the result. We need to remove the inbuilt dataloss which was created with a bias against HTML. We need to respect UX-wysiwyg unless explicitly instructed otherwise. We need to have ux-error-prevention even for cases of allHTML.

> For "Always HTML code should be optional" :
>   Following is possible with current code:
>     User always compose mail in HTML mode.
>     (a) If user wants to send in Text, don't use use color="#000001",
> <B></B> etc.
>     (b) If user wants to send in HTML, use color="#000001", <B></B> etc.
>         Note: this is "Official way to force HTML without
> AutoDowngradeToText", because so coded.
> I think (a) is pretty convenient for user like me, because colorful HTML
> mode can be used any time.
> If "Always HTML code" is not optional, Tb users looses convenient (a) :-)

I'm not sure what you are trying to say here, but using workarounds to control unpredictable application behaviour should never become the norm, no matter how colorful the workaround may be.
(In reply to Arivald from comment #16)

> BTW I know it is not exactly related to the subject of this bug, but this is
> the real problem. Not the conversion problems, not the preferences to select
> HMTL/plain, but fact that we allow user to edit HTML, when we know message
> will be send plain, and our HTML to plain conversion, that does not allow
> user to fix any error.

+1, sending a message which has never been seen or verified by user is NONSENSE, clear violation of UX-control. And conversion is poor (admittedly, it's also hard).

> Thomas, can You evaluate this kind of change? It's implications on current
> logic and UI.

It sounds like something which could be tried, might be doable, and might have merit.
I'm not sure if I'm willing to invest lots of time and brain into this.
It's lots of work for little gain. Who still uses plaintext these days??

> In my opinion it will greatly simplify things.

It would improve things a lot, yes.
So far I was hoping to get away with fixing the worst of what is there, and make that work predictably without unexpected dataloss of formatting.

> I think I could make a proof of concept extension for this, althoug there is
> limit on what can be done from the JS.

Surely welcome.

Still, in the meantime we need to disable auto-degrade to contain the madness, and enforce the send option pref for cases of allPlain (and possible other fixes, my brain is fried from this never-ending saga).
I see.
I stop adding comments to this bug because I've understood that my comments to this bug is meaningless.
(In reply to Thomas D. from comment #18)
> (... Who still uses plaintext these days??

me.
and many (most?) of the posts in newsgroups.
at least half the email I receive that doesn't originate from gmail and exchange.
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #20)

> > (... Who still uses plaintext these days??
> 
> me.
> and many (most?) of the posts in newsgroups.
> at least half the email I receive that doesn't originate from gmail and
> exchange.

Same here. I mostly use plain text in both e-mails and newsgroup/usenet posts for speeds, e-mail sizes, security, etc. Once in a while, I do use HTML format though.
Personally I have very little use for html, but I have users who do and some have problems. I have very little knowledge here - so don't construe my comments as overly insightful, nor do I take sides here.

(In reply to Thomas D. from comment #7)
> (In reply to Charles from comment #5)
> > Thomas, I hope the devs start listening, I'd hate to see you get so
> > frustrated that you leave TB development altogether, you do a lot for the
> > project.
> > 
> > Devs? Please stop knee-jerk dismissing this/these issues, and please try to
> > open your mind and listen.
> 
> +1. I'm really amazed how all of my elaborate, painstaking and long-term
> analysis of current problems, ux-failures etc., across a number of related
> bugs linked up in 'my' meta bug 889315, can just get dismissed with a
> two-liner "ui-review" (Bug 1202276 Comment 7) which is also factually wrong.
> I bet that neither the current behaviour nor the consequences of my patch
> there have been correctly understood. It's damn hard to understand and
> predict the actual outcome of the following factors, all of which finally
> determine the delivery format of your particular HTML message:

perhaps - but I'd be suprised if these alternative comments does not add some very useful perspective. These are all seasoned developers.


> I really want to see that person who can correctly and immediately predict
> the delivery format outcome for all of their various particular formatted
> messages and their particular set of recipients with "delivery-format:
> auto-detect"... Can you???

This for me would be the most aggregious issue.


> And does anyone believe that if we start to change anything in this complex
> system, a two-liner is likely to make a sufficient ui-review? Think again,
> please. I have done a LOT of thinking on this. I'm not saying I'm done with
> thinking, I'm not saying I know it all, but I suspect that there are not too
> many people out there who have a similar overview like WADA and myself, both
> in terms of which problems our users have reported, and in terms of the
> behaviour discussed here. I rest my case. This is extremely tiring,
> especially when all analysis, discussion, and real user problems seen gets
> shot down with a premature ui-r- and alternative solutions which solve
> nothing at all (albeit they improve things). But yes, you need to understand
> the whole damn system to know why they don't.

Given the deep understanding that many of our volunteer developers have in the code, or at least the effects of the code, I suspect you may be overestimating your relative level of insight.

 
> Most of our users just hate it, that's why there's 12,000 downloads of

I don't think we can really know how many users are affected. And 12k downloads is not a large number of users. In fact https://addons.mozilla.org/en-US/thunderbird/addon/always-html/ shows has currently having only 1.4k users, which barely ranks it in the top 400 of addons - hardly overwhelming. 

Also, I don't think this is widely reported in support forums - I don't recall seeing it mentioned.


> TB will do what some plaintext-loving developers once upon a time decided it
> SHOULD do for you...

I seriously doubt the code evolved in this way simply because some developers loved plaintext (even if one were to accept the premise of some developers loving plain text, which we are hardly in a position to state as fact). 


All that said, improvement is definitely needed but I doubt the solutions are simple.
(In reply to Ant from comment #21)
> (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment
> #20)
> 
> > > (... Who still uses plaintext these days??
> > 
> > me.
> > and many (most?) of the posts in newsgroups.
> > at least half the email I receive that doesn't originate from gmail and
> > exchange.
> 
> Same here. I mostly use plain text in both e-mails and newsgroup/usenet
> posts for speeds, e-mail sizes, security, etc. Once in a while, I do use
> HTML format though.

I apologize for the slightly provocative question which wasn't helpful.
There's nothing wrong with composing plaintext, that's why Thunderbird has a plaintext editor, or manual per-message choice of delivery format: plaintext.
There's something wrong with composing HTML and then TB in some cases decides it can just dump my HTML formatting silently to recipients whose preference is "unknown" (i.e. they might prefer EITHER plaintext OR HTML, or even both, right?), in spite of my composition preference for that case set to "ASK me" or "Send both Html+plaintext" (default). Worse when all recipients are plaintext, the preference (to ask or send both) is completely ignored, so we'll silently dump not only so-called "lossless" formatting, but ALL formatting (e.g. inline images).

I have some questions to Wayne and Ant, and everyone here in fact:

1) User composes in HTML mode (default), send option pref set to "HTML+text" (default), 9 recipients set to "prefers-html", and 1 recipient of "unknown". User applies explicit HTML formatting, e.g. direct style sheets on links, or styles which apply to all links without any special attributes on the link. This is how it looks, before and after sending:

(recipients include at least one unknown or plaintext, AND prefers-HTML recipients)
before auto-degrade (attachment 633913 [details] [©] [details]) vs.
after auto-degrade (attachment 633910 [details] [©] [details]).

Would you consider this "lossless conversion to plaintext" (isConvertible==true)?

2) What is stopping you from using plaintext editor to compose plaintext?

3) What is so attractive about composing in HTML when all your HTML formatting will ultimately end up as plaintext, and you want plaintext to begin with?

4) a) Which percentage of our users do you think is using *text-only newsgroups* via TB (and not www)?
   b) Which percentage of global recipients do you think are actually using non-html-capable email service providers? looking at global statistics like this:
http://www.email-marketing-reports.com/metrics/email-statistics.htm
Of course, there's company internal mail and all, but most of them will surely support HTML if only because the most-used OS is MS Windows so they'll probably end up using microsoft outlook, windows mail, or something like that.

5) If we agree that 1) is inacceptable dataloss, even if you insist on composing in HTML for what you want to end up as plaintext, what is stopping you from either
a) explicitly setting prefers-plaintext for your recipients, or
b) explicitly setting per-message delivery-format "plaintext"?
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #22)
> All that said, improvement is definitely needed but I doubt the solutions
> are simple.

Actually, the solution would be quite simple.

Stop silently losing my data!

Why is this so hard to understand?

I think Thomas has done a remarkably good job describing the problem, but the devil has gotten lost in the details.

Fact: Thunderbird, under very well known conditions, silently and unbeknownst to the user, unilaterally decides to strip out all of my carefully crafted HTML - including inline images, etc.

Solution: STOP DOING THIS.
(In reply to WADA from comment #19)
> I see.
> I stop adding comments to this bug because I've understood that my comments
> to this bug is meaningless.

Actually, I think the problem is that you are missing something obvious.

Thunderbird, under certain well known (now that Thomas has painstakingly outlined them) conditions, LOSES THE USERS DATA, silently and without warning.

Fixing this would be very simple, and Thomas has also gone a long way to explaining this too.
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #20)
> (In reply to Thomas D. from comment #18)
> > (... Who still uses plaintext these days??
> 
> me.
> and many (most?) of the posts in newsgroups.
> at least half the email I receive that doesn't originate from gmail and
> exchange.

Irrelevant to the fact that Thunderbird silently and without warning LOSES MY DATA.

Broken record?
(In reply to Charles from comment #26)
> (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment
> #20)
> > (In reply to Thomas D. from comment #18)
> > > (... Who still uses plaintext these days??
> > 
> > me.
> > and many (most?) of the posts in newsgroups.
> > at least half the email I receive that doesn't originate from gmail and
> > exchange.
> 
> Irrelevant to the fact that Thunderbird silently and without warning LOSES
> MY DATA.

You seem confused - My comment here merely provides data, a statement of what I observe as fact, and is certainly not a statement on whether or not there is dataloss nor whether the bug is worthy of of being fixed. I invite you to reread my comment wherein I clearly state I am interested in a fix.  But as implied, not at the expense of my use of plaintext, and balanced with maintaining otherwise expected behavior.

 
> Broken record?

I was invited to comment and add information. Now that I have done so, in the face of such pointless and repetitive comments which add no useful new data I take my leave.
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #27)
> You seem confused - My comment here merely provides data, a statement of
> what I observe as fact, and is certainly not a statement on whether or not
> there is dataloss nor whether the bug is worthy of of being fixed. I invite
> you to reread my comment wherein I clearly state I am interested in a fix. 
> But as implied, not at the expense of my use of plaintext, and balanced with
> maintaining otherwise expected behavior.

Well, I don't see how any of the discussion in the way of was to fix this mess could in any way, shape or form be construed as to be a threat to your ability to use plain text if you so choose.

This is what I meant when I said your comment was (and is) irrelevant.
(In reply to Thomas D. from comment #23)
                                     ^^
Flags: needinfo?(vseerror)
Interestingly, due to executing isConvertible test before looking at recipient preferences, TB even ignores explicit recipient preferences for "HTML" if these are mixed with recipient who prefers "Unknown", "Undefined", or "Plaintext". That's a clear bias for plaintext. Expected result would be for auto-detect to automatically send both formats, so there's alternative part text/plain for prefers-plain and text/html for prefers-html. At least the send option pref (which also defaults to plain+html) should be respected but is not. For *all*Plain it's less surprising to downgrade, but still silent, unstoppable dataloss currently, but that's another corner in the code and filed as another bug, so I won't ride on that here.
Summary: Text alignment gets discarded from HTML compositions when sending (Delivery Format: Auto-Detect; recipient prefers: Unknown) → Text alignment gets discarded from HTML compositions when sending (Delivery Format: Auto-Detect; recipients prefer: HTML(!) & Unknown; Unknown)
I really have no further insight to offer
Flags: needinfo?(vseerror)
Just a brief comment on this "Controversy"

The *ONLY* reason I have been involved with Thunderbird since 0.5a
Is because of it's ability to render HTML/CSS
My history is replete with workarounds, and tricks for the Editor
to do what I want it to do.

Regarding rendering, TB is top of the line

Regarding the ability to compose HTML,
and have it sent as intended, we fail miserably.

I imagine the whole HTML vs plaintext thing boils down to this

Do you want to convey information in your mail
or something more. An emotion, a feeling, a thought

Poets may be able to do that, but I'm no poet
I need HTML/Css to make my point

I fully understand the frustration involved here,
This needs to be fixed,
as well as a better easier HTML composer.
I have this in my preferences:

> Text format
> 
> When sending messages in HTML format and one or more
> recipients are not listed as being able to receive HTML:
>
> Send the message in both plain text and HTML

This is absolutely explicit, yet TB does not obey my preference. It sometimes obeys it, according to a subtle and buggy algorithm that decides that you have 'really' composed in plain text, despite having chosen the HTML composer.

I do not understand how the TB developers cannot see this as a simple bug. However, I'm bored of arguing this, and bored with the noise in my inbox, since the "Always HTML" extension works well enough (for now). I won't be contributing any further.

I'm only commenting here because I don't want the fact that I'm removing myself from the bug CC list to be interpreted as "I don't think this is a bug".
Jorg, is this class of composer bugs something you could look into?
Flags: needinfo?(mozilla)
Yes, in principle. But so could you. I'm currently working on some M-C editor stuff that no one else dares to touch. That will keep me busy until Christmas.

From a quick glance I gathered that people are unhappy that e-mail is sent as plain text. It shouldn't be too hard to locate and fix/change the logic in TB to ship it as HTML.
Flags: needinfo?(mozilla)
Thanks Jorg - so, does this mean that a patch to address the most serious issues as explained by Thomas D., to simply change the behavior to send either HTML or HTML+plaintext, instead of silently auto-degrading to plaintext in spite of users explicit pref settings?

That would be awesome!

Now if someone can do up a patch maybe we can lay this one to rest until it can be fixed properly...
(In reply to Charles from comment #36)
> Now if someone can do up a patch maybe we can lay this one to rest until it
> can be fixed properly...

I don't understand why fixing the send logic in TB wouldn't be a "proper" fix. What else after that needs fixing "properly"??
(In reply to Charles from comment #36)
> Thanks Jorg - so, does this mean that a patch to address the most serious
> issues as explained by Thomas D., to simply change the behavior to send
> either HTML or HTML+plaintext, instead of silently auto-degrading to
> plaintext in spite of users explicit pref settings?

Sorry, left off the last part: would be accepted?

One thing that is confusing me about this is, since apparently the short term fix is pretty easy, who is blocking the ability to fix this in the short run, and why?(In reply to Charles from comment #36)
> Thanks Jorg - so, does this mean that a patch to address the most serious
> issues as explained by Thomas D., to simply change the behavior to send
> either HTML or HTML+plaintext, instead of silently auto-degrading to
> plaintext in spite of users explicit pref settings?

Sorry, left off the last part: would be accepted?

One thing that is confusing me about this is, since apparently the short term fix is pretty easy, who is blocking the ability to fix this in the short run, and why?

(In reply to Jorg K (GMT+2) from comment #37)
> (In reply to Charles from comment #36)
> > Now if someone can do up a patch maybe we can lay this one to rest until it
> > can be fixed properly...
> 
> I don't understand why fixing the send logic in TB wouldn't be a "proper"
> fix. What else after that needs fixing "properly"??

Thomas would be best equipped to answer that since he obviously has a deep understanding off all of the issues...

Thomas?
Sorry for the broken post... tried to fix it in mid-air collision...

Fixed version:

(In reply to Charles from comment #36)
> Thanks Jorg - so, does this mean that a patch to address the most serious
> issues as explained by Thomas D., to simply change the behavior to send
> either HTML or HTML+plaintext, instead of silently auto-degrading to
> plaintext in spite of users explicit pref settings?

Sorry, left off the last part: would be accepted?

One thing that is confusing me about this is, since apparently the short term fix is pretty easy, who is blocking the ability to fix this in the short run, and why?

(In reply to Jorg K (GMT+2) from comment #37)
> (In reply to Charles from comment #36)
> > Now if someone can do up a patch maybe we can lay this one to rest until it
> > can be fixed properly...
> 
> I don't understand why fixing the send logic in TB wouldn't be a "proper"
> fix. What else after that needs fixing "properly"??

Thomas would be best equipped to answer that since he obviously has a deep understanding off all of the issues...

Thomas?
(In reply to Charles from comment #39)

> One thing that is confusing me about this is, since apparently the short
> term fix is pretty easy, who is blocking the ability to fix this in the
> short run, and why?

I have offered a simple 2-line patch which fixes the most relevant cases (except "all recipients prefer plain") in bug 1202276. That bug is currently stalled by Bug 1202276 Comment 7, which imho does not have full understanding of the current behaviour nor patch effects.

> > I don't understand why fixing the send logic in TB wouldn't be a "proper"
> > fix. What else after that needs fixing "properly"??
> 
> Thomas would be best equipped to answer that since he obviously has a deep
> understanding off all of the issues...
> 
> Thomas?

Well, it's so deeply broken that most people do not understand the current behaviour in all its twisted details. Then from simplistic incorrect assumptions about the gravity and confusion of the current behaviour, the need for improvement is sometimes denied or not seen clearly; iow, the issue is still under discussion (after many many years of user complaints left, right, and centre). Both complexity and discussion might necessitate a step-by-step approach to patching.
E.g. if the main culprit, isConvertible() should survive instead of being laid off to the dustbins of history where it belongs, then we need to go back to the drawing board and revisit all the bugs which complain about lossy conversion.

Alas, that patch attachment 8657637 [details] [diff] [review] in bug 1202276 (which is essentially the "Always HTML" addon code), would go a long way to correct the bad behaviours if accepted.
I have fixed this in bug 1384361.

FTR: As a direct result of my continuous advocacy and support from sober and cooperative developers, we've since gone a long way to tame the HTML-eating default behaviour of message-centric Auto-Downgrade which is bundled with recipient-centric Auto-Detect of delivery format (which gets determined after sending). Any tags having style, class, id, or align attributes will now prevent auto-downgrading. However, with TB default settings, Auto-Downgrade will still silently change the look and feel of your simple messages from predictable HTML layout to unpredictable, odd-looking plaintext. Here's the good part for anyone who never wants TB to auto-downgrade their HTML messages to plaintext: Since my implementation of bug 136502, Auto-Downgrade is now *optional* and may be switched off completely:

> Tools > Options > Composition > General > Send Options > [ ] Send the message as plaintext if possible (remove the checkmark)
> (pref: mailnews.sendformat.auto_downgrade=true|false)

So "Always HTML" addon is no longer required to fix this problem. As to what exactly this pref does or doesn't do, see bug 136502 comment 168.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1384361
You need to log in before you can comment on or make changes to this bug.