User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 if an image is paste from the clipboard (ALT+ Prn scr then CTRL-V) and the Format option is set to Auto-Detect, the image appears in the body but is not sent. That was working fine before release 3.1.1 (one or two releases back). Now I always have to think to switch the Format Option to Rich Text (HTLM) before hitting Send or re-send the email each time. Reproducible: Always Steps to Reproduce: 1.click on any window 2.press ALT + Prn Scr (Print Screen) 3.in TB, create a new message and in the message body, press CRTL+V to paste the image 4.click on Send Actual Results: The image is not sent as part of the email Expected Results: image sent with the email That was working fine before release 3.1.1 (one or two releases back).

Can you define a bit more which version it worked on ?

can't say exactly which one but I think the latest of versions 2 were working fine and then earliest versions 3 broke it down

bug still present in version 3.1.2 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2)

As "Format option is set to Auto-Detect"(defaulted always, unable to change default choice currently), if you set recipient's attribute as "Prefer Plain Text" in address book, and if recipients are of "Prefer Plain Text" only, Tb automatically sends mail in "Plain Text Only" mode. This case? You can check sent mail data structure without sending. Use "Send Later" and view mail source at "Outbox" of "Local Folders".

All contacts are set to "Unknown" (default never set/changed)

bug still present in version 3.1.3 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3) sucks major

noticed that TB adds a space to the beginning of the message (started to do that a few releases back). Maybe that's causing this bug (improperly auto-recognizing message format). Please, check this bug and fix the extra space at the beginning of the message. Thanks in advance

(In reply to comment #7) > noticed that TB adds a space to the beginning of the message (started to do > that a few releases back). Maybe that's causing this bug (improperly > auto-recognizing message format). Please, check this bug and fix the extra > space at the beginning of the message. > > Thanks in advance That's bug 564737 we are aware of it and working on it.

new version and yet no fixes on those bugs. exactly what got fix? some obscure security bug that a 12 y/o dork discover in the basement? I understand that both Firefox & Thunderbird are free and community developed, but those are simple bugs that should be fixed a.s.a.p. if you don't, next thing is for me to move to IE9 and Live Essential Mail. same deal: free

Francois (reporter), do you still see this issue? scenario of comment 0 is wfm on TB12/winXP a bit odd is scenario along comment 4, if recipient is marked "prefers plaintext", we don't prevent inline images and html formatting (even in case of write-to from AB), then, when sending, inline img is lost without notice. I think I saw a bug for that...

(In reply to Francois from comment #5) > All contacts are set to "Unknown" (default never set/changed) HTML preference "Unknown" in Address boook, and mail address which is not defined in Addrss Book, looks same as preference of "Plain Text" for Auto-Detect of Tb. (0) Tools/Options/Composition/General, Send Options... = "Ask me what to do" Mail recipients : auto-detect-prefer-html@x.x.x : preference=HTML auto-detect-prefer-text@x.x.x : preference=Plain Text auto-detect-prefer-unknown@x.x.x : preference=Unknown auto-detect-prefer-undefined@x.x.x : no mail adress any Address Book Send Later, with keeping Option/Format/Auto Detect. Checked with Tb 14.0 on Win-XP. (Case-A) text only in HTML, no formatting. (1) To: auto-detect-prefer-html@x.x.x, auto-detect-prefer-text@x.x.x, auto-detect-prefer-unknown@x.x.x, auto-detect-prefer-undefined@x.x.x Following is required for text color. <font color="#ff0000">Auto-detect-test #1 : with color</font> => Which format(HTML+Text, HTML only, Text only) was asked. (2) To: auto-detect-prefer-html@x.x.x, auto-detect-prefer-text@x.x.x, auto-detect-prefer-unknown@x.x.x, auto-detect-prefer-undefined@x.x.x Following text only in HTML message body. "Auto-detect-test #2 : with no formatting" => Which format(HTML+Text, HTML only, Text only) was not asked. Tb silently sent mail in text/plain. (Case-B) inserted image only in HTML messega body (3) To: auto-detect-prefer-text@x.x.x, auto-detect-prefer-unknown@x.x.x, auto-detect-prefer-undefined@x.x.x Inserted image only(local image file) in HTML message body. => Which format(HTML+Text, HTML only, Text only) was asked. (4) To: auto-detect-prefer-text@x.x.x Inserted image only(local image file) in HTML message body. => Which format(HTML+Text, HTML only, Text only) was not asked. Tb silently sent mail in text/plain. (5) To: auto-detect-prefer-unknown@x.x.x Inserted image only(local image file) in HTML message body. => Which format(HTML+Text, HTML only, Text only) was asked. (6) To: auto-detect-prefer-undefined@x.x.x Inserted image only(local image file) in HTML message body. => Which format(HTML+Text, HTML only, Text only) was asked. (In reply to Francois from comment #0) > if an image is paste from the clipboard (ALT+ Prn scr then CTRL-V) and the > Format option is set to Auto-Detect, the image appears in the body but is > not sent. That was working fine before release 3.1.1 (one or two releases > back). (In reply to Francois from comment #5) > All contacts are set to "Unknown" (default never set/changed) (Q1) Do you still see your problem in recent Tb 14? (Q2) Is actually all recipients preference "Unknown" in any Contact which has email address of a recipient? (Q3) What is your choice at Tools/Options/Composition/General, Send Options...? (Q4) Is "Attach this image to the message" checked at Image Properties of the pasted image to HTML body? As for text only HTML mail case, I think "preference=Unknown" and "not defined in Address Book" is beter interpreted as "preference=HTML" nowadays. I bellieve "silent downgrade by Auto-Detect to text/plain from text/html when no need of HTML formatting" should be applied to "preference=Plain Text" only nowadays. Problem due to "mail is sent in text/plain even though user composed mail as HTML" is far worse nowadays than problem due to "mail is sent in HTML even though formatting by HTML is not required".

To Thomas D., bug opener never referred to "preference=Plain Text", rather he says default of "preference=Unknown" in Address Book is always used. How could you know that bug opener's case is "preference=Plain Text" case? Note: As seen in my test, your new bug summary is correct, but there is still no evidence that original problem of comment #0 and other comments by bug opner is problem which you cited in your new bug summry.

(In reply to Francois from comment #9) > if you don't, next thing is for me to move to IE9 and Live Essential Mail. I'm very appriciated if you would do the "next thing for you", because I won't see such threat to developers any more at B.M.O where to report Tb's bug to developers and to ask them for fixing of Tb's bug. As for bypassing issue of "silent downgrade to text/plain by Auto-Detect even though composed as HTML mail by you", some simple ways are already known. (a) By signature : <B></B> in HTML signature, or one of some other HTML tags. (b) msgcompose.text_color = black, or #000001 etc., or msgcompose.background_color = white, or #FFFFFe etc. Because attribute of <BODY> tag is changed from following by the setting, <body bgcolor="#FFFFFF" text="#000000"> Tb's Auto-Detect won't try to downgrade to text/plain. You can try them before you transfer to IE9 and Live Essential Mail, if you still use Tb.

FYI. Following is major Auto-Detect relevant bugs. > Bug 414299 : It looks bug for spec of "what is formatting-by-HTML-is-not-needed". > Bug 136502 : This is request from users who experienced problem like yours. > They asked way to change default of Options/Format from Auto-Detect > to other, instead of threating Tb developers.

Similar: bug 180997 per current summary... Bug 584363 - Format Option Auto-Detect: Inline images lost when sending to recipient who "prefers to receive messages formatted as: plain text" ...this might be a dupe of bug 180997: Bug 180997 - Inline images or embedded local files silently stripped without trace when force-sending HTML message in plaintext mode (Options > Format > Plain Text only: img lost; need warning and/or conversion into attachments) However, per Wada's comment 12, it's not clear if the current summary (involving recipient preference for plaintext) matches the original problem of this bug (involving recipient preference unknown).

(In reply to Thomas D. from comment #15) > ...this might be a dupe of bug 180997: Many of bugs relevant to Auto-Detect starts with same phenomenon; Even though user composed mail in HTML long the way, Auto-Detect of Tb silently sends it as text/plain mail. Differences among bugs is complaints on it, claim on it, or request for improvement. (i) Auto-detect shouldn't convert to Text when some HTML tag usage (ii) "Use Auto-Detect or not" should be customizable (iii) Default of Options/Format should be confifuarable All these requests is request even on "prefers to receive messages formatted as: Plain/Text". As written in comment #5 by bug opener, this bug's case is "prefers to receive messages formatted as: Unknown" case. So, other improvement is possible without changes like above. (iv) Improvement in decision to do downgrade or not, which is based on "preference" setting in Address Book.(perhaps new from Tb 3) - Do "downgrade to Text from HTML silently" only when all recipients are defined as "prefers Plain/Text" in Address Book. - Ask for "format of mail" always when not "all prefers Plain/Text". - Treat "prefers to receive messages formatted as: Unknown" in Address Book as "prefers Text/HTML". I believe this is acceptable nowadays. - Treat "recipient is not defined in Address Book" as "prefers HTML". I believe this is acceptable nowadays. This request (iv) doesn't change behaviour on "prefers to receive messages formatted as: Plain/Text" recipient. Changing bug summary to reflect above request of (iv). And changing to NEW. Severity=Enhancemet is better?

(In reply to WADA from comment #16) Thanks WADA for your detailed and spot-on analysis of the problems around Format > Auto-Detect. > (In reply to Thomas D. from comment #15) > > ...this might be a dupe of bug 180997: > > Many of bugs relevant to Auto-Detect starts with same phenomenon; > Even though user composed mail in HTML long the way, > Auto-Detect of Tb silently sends it as text/plain mail. +1, it's a pita > Differences among bugs is complaints on it, claim on it, or request for > improvement. ...all sharing the same problem: current behaviour of Format > Auto-Detect and its interaction with other relevant settings is unexpected, unpredictable, unwanted, violating ux-principles. > (i) Auto-detect shouldn't convert to Text when some HTML tag usage > (ii) "Use Auto-Detect or not" should be customizable > (iii) Default of Options/Format should be confifuarable +1. > All these requests is request even on "prefers to receive messages formatted > as: Plain/Text". Iow, even plain-text lovers (I haven't met many so far) will benefit from better behaviour and control over auto-detect along the lines of above suggestions (i)-(iii). > As written in comment #5 by bug opener, this bug's case is "prefers to > receive messages formatted as: Unknown" case. > So, other improvement is possible without changes like above. > (iv) Improvement in decision to do downgrade or not, which is based on > "preference" setting in Address Book.(perhaps new from Tb 3) > - Do "downgrade to Text from HTML silently" only when all recipients > are defined as "prefers Plain/Text" in Address Book. Probably yes. > - Ask for "format of mail" always when not "all prefers Plain/Text". Yeah, but generally speaking, we're trying to avoid asking, which is just a nuisance to most users as they don't understand what the question is about, and it's no longer required because the urgent need for sending plaintext is basically gone these days. > - Treat "prefers to receive messages formatted as: Unknown" in > Address Book as "prefers Text/HTML". > I believe this is acceptable nowadays. +1, definitely! > - Treat "recipient is not defined in Address Book" as "prefers HTML". > I believe this is acceptable nowadays. +1, definitely! > This request (iv) doesn't change behaviour on "prefers to receive messages > formatted as: Plain/Text" recipient. Probably. I find it really hard to understand the interaction of all relevant settings and behaviours. And I'm definitely a more-than-advanced user of TB. For normal users, imho there's almost no chance to make this behave according to their expectations with the current set of behaviours, settings and UI. > Changing bug summary to reflect above request of (iv). > And changing to NEW. Severity=Enhancemet is better? No, "image lost" without warning is dataloss, and even with warning it's still dataloss. Dataloss is a bug. Notwithstanding the historical benefit of auto-detection when users still had to fight with bandwidth limits and text-only mail readers, the whole setup and behaviour around Format > Auto-Detect looks more like a bug than a feature to me, and is really an anachronism these days, very annoying. It's high time to sort this out in a more radical manner to return ux-control to the user and stop violating ux-efficiency, ux-wysiwyg, ux-discovery etc. (And as a sidenote, I've never heard anybody except one particular person who is happy with the status quo). Users who prefer sending plaintext should compose in plaintext, or force plaintext when sending. TB should stop messing with the rest of us who correctly expect that composing in HTML means sending HTML (+ optional plaintext), respecting ux-control and ux-wysiwyg in the sense of (Composition HTML==Outgoing HTML) (with a high chance of the receiver seeing much the same what sender sees; if recipient isn't able or willing to see HTML, that's an entirely different story, and very rare these days). The whole idea of downgrading HTML compositions (no matter how little HTML they might have) and sending plaintext only is a contradiction in itself, and surely no longer appropriate as a dataloss default behaviour forced on everyone. For details of how Auto-Detect crushes deliberate user formatting, especially styles that happen to be in the wrong tags deemed ignorable by Auto-detect, see some of plenty testcases on bug 414299, e.g. attachment 633908 [details] (HTML composition, before Auto-Detect) VS. attachment 633910 [details] (plaintext sent & received, after Auto-Detect) I think the pics say more than many words. Unfortunately, the author of Auto-Detect code so far has been rather unwilling to acknowledge or fix such problems, and more often than not he is creating an impression of actively preventing any progress in this matter and defending every inch of the status quo tooth and nails against the majority opinion and accepted ux-principles because of his obvious personal preference for sending plaintext-only as often as possible (which, for added obfuscation, he also denies in public).

(In reply to Thomas D. from comment #17) > For details of how Auto-Detect crushes deliberate user formatting, > especially styles that happen to be in the wrong tags deemed ignorable by > Auto-detect, see some of plenty testcases on bug 414299, e.g. > > attachment 633908 [details] (HTML composition, before Auto-Detect) VS. > attachment 633910 [details] (plaintext sent & received, after > Auto-Detect) > > I think the pics say more than many words. Nota bene that this what currently happens as soon as there's a single recipient of type "prefers to receive messages formatted as: *Unknown*" or a single recipient *not yet listed* in your AB (both of which are frequent scenarios), due to these: Obsolete assumptions of Auto-Detect algorithm (addressed in WADA's comment 16): prefers to receive messages formatted as: Unknown -> prefer plaintext for sending new address not yet in AB -> prefer plaintext for sending Also note that when sending to new addresses, TB will auto-save these to AB with preference: Unknown, increasing the number of recipients with that "preference", i.e. increasing the number of everyday cases where Auto-Detect unwarrantedly downgrades HTML compositions to plaintext.

Tohmas D., I don't think stating "how image is important", "how formatting is important", adding "complaints on Auto-Detect", is needed. Current Auto-Detect's decision is pretty simple. (1) If all recipients are "Prefers HTML people", send in HTML silently. (2) If all recipients are "Prefers TEXT people", send in TEXT silently. (3) If recipients are mixture of "Prefers HTML people" and "Prefers TEXT people", ask user for format. Current problem is; - If recipient is defined in Address Book with prefer=Unknown or is not defined in Address Book, these recipients are treated as "Prefers TEXT people" by Auto-Detect, then mail is sent in TEXT silently by Auto-Detect. - And, because many users never set HTML or TEXT preference in Address Book, and because default of HTML or TEXT preference in Address Book is "Unknown", HTML mail is usually sent in TEXT silently by Auto-Detect(almost always, if simple HTML mail), unless user compose actually fully Rich Text HTML mail, or unless user inserts dummy tag such as <B></B> in HTML mail(Never say nonsense, please, because it's current implementation by developer of Tb.) My proposal is merely; Change category of "defined in Address Book with prefer=Unknown" and "not defined in Address Boook" to "Prefers HTML people". > Category in Auto-Detect > (AB = Address Book) Current My proposal > Defined in AB, prefer=HTML : Prefers HTML people Prefers HTML people > Defined in AB, prefer=Unknown : Prefers TEXT people Prefers HTML people > Not defined in AB : Prefers TEXT people Prefers HTML people > Defined in AB, prefer=TEXT : Prefers TEXT people Prefers TEXT people After my proposal, HTML mail is silently sent in TEXT, only when all recipients are explicitly defined in Address Book as "preference=TEXT". Because user intentionally sets "preference=TEXT" in Address Book for the recipients, "silently send in TEXT" is acceptable behavior, and it's never changed from current. If recipients are mixed, format is asked, but it's never changed. It's absolutely same as current. And, after change of my proposal, any combination of "recipient who is defined in Address Book as preference=HTML", "recipient who is defined in Address Book as preference=Unknown", "recipient who is not defined in Address Book", is categorized in "All are Prefers HTML peoples". So, mail is sent in HTML by Auto-Detect, even when Auto-Detect is internally invoked. Please note that my proposal never touches Auto-Detect itself. Merely changes "Category of recipient" only, or "Default interpretation of HTML or TEXT preference in Address Book" only.

(In reply to WADA from comment #19) > Thomas D., I don't think stating "how image is important", "how formatting > is important", adding "complaints on Auto-Detect", is needed. Ymmv, but I think as long as Delivery Format Auto-Detect is causing dataloss to our users and violating ux-principles like ux-wysiwyg, this needs campaigning until it's corrected. > Current Auto-Detect's decision is pretty simple. > (1) If all recipients are "Prefers HTML people", send in HTML silently. > (2) If all recipients are "Prefers TEXT people", send in TEXT silently. > (3) If recipients are mixture of "Prefers HTML people" and "Prefers > TEXT people", ask user for format. At the time when you wrote that comment, that was wishful thinking wrt scenario of (3) mixed HTML vs. plaintext preference recipients, and I've seen bugs reporting otherwise (auto-detect would just plaintext w/o asking). Also, "ask user for format" is never default setting; even if "ask" is active, if auto-detect believes there's no HTML/css worth keeping, any such HTML/formating will still go down the drain w/o asking. We might have improved in this corner because Joshua's js mime bug recently touched some of the logic, which I think now ensures including HTML version if some recipients listed as unknown or HTML. We should try to verify what has been fixed.

Is this still happening? I can't reproduce this. I pasted an image into a HTML composed email and have chosen a recipient from addressbook that has his HTML preference set to Unknown. I saved it as draft. The image is there in the message source. What do I need to reproduce this? Reporter, please see what is set in Options->Composition->General->Send options .

(In reply to Francois from comment #0) > Reproducible: Always > Steps to Reproduce: > 1.click on any window > 2.press ALT + Prn Scr (Print Screen) > 3.in TB, create a new message and in the message body, press CRTL+V to paste > the image > 4.click on Send > Actual Results: > The image is not sent as part of the email I still can not reproduce such phenomenon in Tb 38.2.0 with "No text formatting + <img> only", with Delivery-Format=Auto-Detect, recipient is prefs=Unknown or not-defined-in-AddressBook, with Ask in Send Options, With No Text Domain, With No HTML Domain setting, as I couldn't reproduce such phenomenon in comment #11. i.e. Always Asked by "Send Options" setting. I could observe "mail composode in HTML mode is silently sent as text/plain" only when recipients is prefers Text case only(case-B, (4) in comment #11), in same test(case-B in comment #11, image only, or image + formatless text only) except "difference of messaage preference setting in Address Book". i.e. Send Options worked as designed/as implemented/as expected. I could see phenomenon of (2-2) in User Story of bug 1204379 only(test with non-formatted-text only). To bug opener and problem reporters in this bug: Do you still see problem of this buh(not your problem around Auto-Detect) in recent Thunderbird releases such as Tb 38? If recipient's mail domain is set in Text Domain, or if "Send Options" setting is "send in Text Plain only", mail is sent as text/plain according to your request in Send Options, message preference setting in Address Book. If no problem in recent releases, and if you set some other mail domains in Text Domain or you have mail address of Prefers=Text, it might be fault in mail address matching of old Tb like next; When abc.def.ghi is set in Text Domain, xyz@def.ghi is wrongly treated as Text Domain mail address When def.ghi is in Text Domain, pqr.def,ghi is treated as Text Domain even though definition is not *.def.ghi Whaat kind of mail was sent? text/plain mail? text/html mail but no img tag, no cid: URL in html, no embed image part, etc.? If latter, it might be problem in handling of pasted image data.

(In reply to :aceman from comment #21) > I saved it as draft. The image is there in the message source. "Save As Draft" keeps mail composition mode because mail composed in HTML mode is saved as text/html and mail composed in Text mode is saved as text/plain. Downgrade to Text then send as text/plain, send as text/html, send as multiprt/alternative, is executed by Send/Send Later. Anyway, change back to UNCONFIRMED according to comment #10, comment #11, and comment #22, which are comment of "unable to reproduce this bug with STR in comment #0", although I changed to NEW because bug opener repeatedly said "this bug still occurs" and "phenomenon of mail is silently sent as text/html although mail is composed in HTML mode" surely occurs if some conditions are met.

Another reason why I changed to New was "tried to change to Enhancement request bug", but I forgot to change to Enhancement. Sorry for my confusing Status: field update.

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Closing as WORKSFOME, according to comment #10, comment #11, and comment #22, which are comment of "unable to reproduce this bug with STR in comment #0". Bug opener, if WORKSFORME(problem can't reproduce. If bug actually existed, already resolved by unknown patch) is wrong, please re-open.