User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Steps to reproduce: Compose mail, and insert remote image. Actual results: It pretends to include remote image, but it does not include the remote image when the e-mail is sent. Expected results: When outgoing email is set to default to text, and a remote image is inserted, the delivery format should automatically be changed to html so that the remote image is included in the e-mail instead of fooling the sender into thinking that it was included. Furthermore, when clicking on Options, Delivery_Format, the current setting should be highlighted, to indicate the current delivery format, as clicking to change the delivery format shows no indication of what delivery format is being used. Also it would be nice if there was some indication that would show up in all of the compose windows showing what delivery format is being used. Wayne Sallee Wayne@WayneSallee.com

Well, this never happens to me. I compose e-mail in HTML and when I include images, the e-mail gets sent as HTML. Plain looking e-mail without any formatting is downgraded to plaintext, since I have Tools > Options, Composition, General, Send Options (button): Send message as plain text if possible. We've worked very hard not to downgrade anything that's not downgradable. So somehow you must force sending plaintext and then you complain the the system does what you've asked for? How exactly do you do the "outgoing email is set to default to text"?

You say "So somehow you must force sending plaintext" I don't know how I would be "forcing" plain text. Yes I have "Send message as plain text if possible." checked. What do you have for the setting "When sending messages in html format and one or more recipients are not listed as being able to receive html" ? "Send the mail in html anyway"? Does "not listed" mean "no preference given", or "preferred text" I did not have this problem before the recent update. Wayne Sallee Wayne@WayneSallee.com http://www.WayneSallee.com

Well, sadly I've seen a few bugs like yours, all the duplicates of bug 1510134 ... here goes one more. I have: "Send the message in HTML anyway". "Not listed" refers to the address book entry of the recipients. They can state: Prefers to receive messages formatted as: Unknown/Plain Text/HTML. So if you have recipients with "Unknown" and you don't have "Send the message in HTML anyway", the message will be forced to plaintext. Somehow something seems to have changed since this is the fourth complaint :-( - I'm not aware of any changes.

Also I failed to make it clear in my first post that clicking to change the delivery format to html makes it work. I touched on this in my first post, but failed to state that changing the delivery format to html makes it work. But my point is that when the remote image is added to the e-mail, that thunderbird should automatically change it to html, instead of requiring the user do do so, fooling the user into thinking that it is inserted in the e-mail. Wayne Sallee Wayne@WayneSallee.com http://www.WayneSallee.com

You wrote "So if you have recipients with "Unknown" and you don't have "Send the message in HTML anyway", the message will be forced to plaintext." Then that's exactly what is happening. Thunderbird must have change the way it interprets this. Doesn't "Send the message in HTML anyway" force html to be sent to those that don't want html? Or does it just ignore the fact that some are unknown, and sends text to those that only want text? Wayne Sallee Wayne@WayneSallee.com http://www.WayneSallee.com

Ok setting "Send the message in HTML anyway" does correct the problem, and if the receiver is set to prefer text, it will correctly send it a text instead of html (no picture), which is good so it won't be sending html to text only mailing lists. Wayne Sallee Wayne@WayneSallee.com http://www.WayneSallee.com

Thomas, can you please take care of this. Once we were working on a grander solution for this, but it got canned :-( - Bug 1222176. (In reply to Wayne Sallee from comment #5) > Doesn't "Send the message in HTML anyway" force html to be sent to those > that don't want html? > Or does it just ignore the fact that some are unknown, and sends text to > those that only want text? I don't know the exact detail. It could also be that the message is sent as plaintext + HTML. Aceman, are you aware of any changes in this area. We've piled up four duplicates so far.

(In reply to Jorg K (GMT+1) from comment #7) > I don't know the exact detail. It could also be that the message is sent as > plaintext + HTML. > I tested it, and with "Send the message in HTML anyway", if receiver is set at plain text, the receiver will get plain text. With it set as "Send the message in both plain text and html" the receiver will get plain text. In the above settings, if the receiver is set to unknown, the receiver will get htm, or html with text, according to the above settings. Wayne Sallee Wayne@WayneSallee.com http://www.WayneSallee.com

On thing that I think would help: before sending mail; if a picture is attached; if a recipient will not be receiving the picture; Send popup telling user that $recipient won't be getting the image, and why. Then the user can fix the problem, and resend, instead of getting frustrated days later when the user realizes that the picture never got sent. Wayne Sallee Wayne@WayneSallee.com http://www.WayneSallee.com

One option is to ask.

(In reply to Jorg K (GMT+1) from comment #7) With default settings, as Jörg said, this bug cannot happen. Can happen when *all* recipients are "prefers-plain" (bypassing any options set), or with option "Convert the message to plain text" set. Am surprised to see more reports of this now, maybe something changed as Jörg suspected. > Thomas, can you please take care of this. Once we were working on a grander > solution for this, but it got canned :-( - Bug 1222176. Indeed. It's a can of worms and I have painstakingly described every single worm/bug and offered systemic remedies which would have allowed us to preserve the existing concept but remove its unpredictability/inherent disfunctionality. It was well-considered to the very detail and ready to land but wontfixed in the last minute by Magnus. Imho he was right to recommend that the entire feature set should be removed; however until that actually happens, we'll also remain with all the bugs, which is unfortunate. So this is the status quo: This is what we currently pretend to offer: * Predictable, recipient-centric, post-composition message format determination/conversion (esp. downgrading to plaintext as required/desired) Unfortunately, that's a myth. Here's the sad truth (sorry for the complexity, which is in the matter): 1) The whole idea of downgrading to plaintext AFTER allowing full HTML composition process is inherently NONSENSE, massive violation of ux-principles (ux-error-prevention, ux-control, ux-wysiwyg, you name it) - I mean really, that's like spending time to prepare a fancy meal and then trashing it into a blender just before serving to recipients, without ever looking at what they actually get. Who wants that!? 2) Worse post-composition downgrading WITHOUT WARNING - that should NEVER happen, blanket blender opt-in to shoot yourself in the foot with silent dataloss, see above. This bug. 3) The idea of *recipient-centric* format determination has very limited application these days (text-only newsgroups??), is all but impossible to ever get right for mixed-type recipients, hence inherently leading to undesired/unpredictable/self-contradictory processes/results. Making it safe AND right would certainly violate ux-minimalism, cause ux-interruption, etc. 4) Even if we were to subscribe to the idea of recipient-centric, post-composition, multi-type-recipient format determination: Our current set of options, their wording, their behaviour, their inherent design are all fundamentally broken (see below). 5) Wording: "When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML" - wtf? As reporter's comments show, this is very hard to understand. I guess many users will misread this as "are listed as NOT being able to receive HTML = prefers-plain", because essentially, this option seems to be for conflict resolution - msg is HTML, but at least one recipient prefers plain text, what should TB do? That's an outdated conflict. Moreover, none of the available options other than the default actually solve the conflict (see below). Wording does NOT indicate at all that de facto, this ALSO sets the default format for the majority of messages, where the recipient's format preference is unknown. 6) Plain-text bias: This option confusingly covers both default format for "unknown" and conflict resolution for "plain", and inherently assumes that the conflict resolution must be the same for both groups, somehow based on the outdated, biased assumption "unknown = prefers-plain", which is no longer applicable. Most of today's recipients can receive HTML, so there's no conflict hence no need for conflict resolution like downgrade/ask/send both in the first place. The combo of "Send messages as plain text if possible" (content-centered), otherwise defaulting to "HTML only" works just fine for 99% of today's cases. Defaulting to HTML + Plaintext as we do is actually pretty bad as it bloats every message, even if there isn't a single plaintext recipient, so the plain-text alternative probably never sees the light of day except cluttering inboxes. But we can't easily change it because the option is overloaded. Or maybe we just could. 7) Wording vs. behaviour: A "prefers-plain" recipient is one which is "not listed for HTML", right? So one would think conflict resolution option should apply? Alas, it will only apply when there are /different/ types of recipients, e.g. at least (one unknown OR prefers-HTML) AND (one prefers-plain). You can have "Send the message in HTML anyway", BUT, IF there are ONLY plain-text recipients, i.e. when conflict resolution matters most, it will NOT apply. So sometimes it will apply for plaintext recipients, and sometimes not. Happy guessing :/ (Note that reporter's test results were wrong/incomplete because he didn't test the mixed-type case - that's how much we confuse our users...). 8) Options do NOT solve the conflict: So let's assume you're one of the 1% of users who actually want recipient-centered format determination, e.g. for plaintext-only newsgroups: * "Ask me what to do": Not an option because it also applies to "unknown", so it would ask you every time (ux-interruption). Would be helpful IF conflict resolution was only applied to messages involving explicit "prefers-plain", and users could set "unknown = accepts HTML". * "Convert the message to plaintext": Wow, worse. Silently discards ALL of your HTML messages to unknown recipients (dataloss, ux-wysiwyg, ux-error-prevention...). Unusable as long as the option covers "unknown". * "Send the message in HTML anyway": Yea, that would be good as a default for unknown, but then it doesn't work if you add a prefers-plain recipient who needs the plaintext alternative. So this is also useless for conflict resolution for where it really matters, for prefers-plain. Still, might make a better default? * "Send the message in both plain text and HTML". That's the only option which works for the typical user who normally wants HTML for unknown, AND for the exceptional user who sometimes needs plaintext for prefers-plain. It's a bad option again because it bloats each and every message to unknown recipients which can normally read HTML-only very well (at least no known email client will choke on it, not even PINE). It's not a very good solution for the text-only newsgroup again, which may choke (or does it really?). 9) Bottom line: The cardinal UX error here is that the option covers apples and pears: * default format determination for "unknown" (useful default: HTML only) * conflict resolution options for "prefers-plain" (useful default: Send both / Ask) What's good for the former is bad for the latter, and vice versa. That's what bug 1222176 was trying to disentangle. Also note that this option is commonly regarded as "setting the default message format" (between HTML only vs. Plain+HTML), which is not exactly true and as far as it does work to that end, it is not at all obvious from the current UI location and wording. > (In reply to Wayne Sallee from comment #5) > > Doesn't "Send the message in HTML anyway" force html to be sent to those > > that don't want html? It should according to the wording of options, but it doesn't work reliably. See 7) above. > > Or does it just ignore the fact that some are unknown, and sends text to > > those that only want text? We do not send differently formatted messages to different recipients if that's your question. > I don't know the exact detail. It could also be that the message is sent as > plaintext + HTML. If you send to plaintext recipients ONLY, message will ALWAYS silently discard all HTML, even if you have "Send message in HTML anyway". Otherwise (mixed recipients) your chosen option will apply, if your faith is strong and you pray hard ;-) > Aceman, are you aware of any changes in this area. We've piled up four > duplicates so far. I agree with Jörg that it's surprising to see more reports claiming that this has changed. Maybe something in the update and/or an addon messed up users existing pref setting for this option?

(In reply to Thomas D. (currently busy elsewhere) from comment #11) > 4) Even if we were to subscribe to the idea of recipient-centric, > post-composition, multi-type-recipient format determination: Our current set > of options, their wording, their behaviour, their inherent design are all > fundamentally broken (see below). I forgot to mention the current UI blunder that the current wording in Tools / Options is Text Format / Send Options whereas per the current post-composition blender logic it's really about "Delivery Format: Auto-Detect", but unfortunately neither of these terms appear in the options. Because the whole magic (also plaintext/HTML domains iirc) only applies if you don't override Delivery Format: Auto-Detect to any of the defined formats (plain/HTML/both) on a per message basis.

(In reply to Thomas D. (currently busy elsewhere) from comment #11) > (In reply to Jorg K (GMT+1) from comment #7) > Very Well put Thomas. As for the change: After one of the updates, e-mails going to text only mailing lists started going as html, so I had to make changes to correct this. Then after another update, I ran into this issue, where html was going as plain text, so I had to make changes again. I so totally agree that e-mail being composed, should be composed as it will be sent, not changing what you composed after you hit the send button. I also find the "send as both text, and html" useless, and confusing to many. It just bloats the e-mail, and confuses people into thinking that e-mail is being sent to different people with different formats. Wayne Sallee Wayne@WayneSallee.com http://www.WayneSallee.com

Wow, thanks Thomas for your encyclopedic summary. I'll dupe this to bug 1510134, but the issue has gotten back onto the radar, check my PM.