User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170508114559 Steps to reproduce: I set Thunderbird for composition in plain text only. Then I send a Simple Mapi email. Actual results: Despite clicking "Write" correctly open the composition in plain text, via Simple Mapi the email is HTML regardless of any option I've tried, and the unpleasant result is that you get everything on a single line because CRLF obviously don't make sense to the HTML format. Expected results: If Thunderbird is set for default plain text composition, Simple Mapi should respect the default as it happened before. In fact, this doesn't happen with v. 38. and as a workaround I actually downgraded to v. 38 as soon as I discover this bug. I can't tell what's the most recent version without this bug. The option for plain text I've tried without success are: Account->composition, uncheck "Compose message in HTML format" (With v. 38 this that's the only necessary option) Preferences->Send Options->Send messages as plain text if possible (checked) Plain text Domains: *.* Also tried there: "Convert the message to plain text" just to check if could be a workaround.... but it is not. into Advanced->config editor mail.html_compose = false mail.identitity.default.compose_html = false mail.identitity.id1.compose_html = false (there is only 1 account)

I've discussed this at length in bug 1359418. Can you not use <br> to break your text into lines?

== The first problem is that our requirement is that the email must not be sent in HTML format, so it's not a matter of using <br> or not. By the way, plain text is OK for everything, HTML is not. E.g. many server only accept commands in plain text. Forcing the use of HTML for MAPI was not a great idea! == The second problem is that only Thunderbird force HTML so is NOT COMPLIANT with the rest of the world. This introduce another problem... == The third problem is that we cannot know which mail client the new customer is using. Could be Outlook Express, Outlook, Mail, Live mail or Thunderbird or others Simple MAPI compliant. Now, the only client with problems is Thunderbird. All the others clients DO NOTHING other than using the same setting for MAPI and when the user click "Write" in the UI: -- If the account is set for HTML, the message via MAPI will be treated as HTML -- If the account is set for PLAIN TEXT, the message via MAPI will be treated as plain text Isn't that simple? Plain Text -> MAPI -> TB set for Plain text => OK Plain Text -> MAPI -> OL set for Plain text => OK Plain Text -> MAPI -> OL set for Plain text => OK etc. for other clients HTML -> MAPI -> TB set for Plain text => NOT OK HTML -> MAPI -> OL set for Plain text => NOT OK HTML -> MAPI -> OL Express set for Plain text => NOT OK etc. for other clients HTML -> MAPI -> TB set for HTML => OK HTML -> MAPI -> OL set for HTML => OK HTML -> MAPI -> OL Express set for HTML => OK etc. for other clients I cannot use HTML in any case because the requirement is PLAIN TEXT. So I can't change CRLF into <br> because the email must be plain text in any case and Thunderbird isn't able to do that anymore. :-/ I can't figure out because you lock on HTML instead of using the option of the account. === WORKAROUND The only workarounds you left me with are: 1) Tell all our hundreds of customers to stay on the old version of Thunderbird (I've already downgraded some) 2) Tell them, (especially the new ones), not to use Thunderbird anymore, despite we recommended Thunderbird as first choice till now. There is no choice unless you decide to use the account flag "Compose messages in HTML" not only for manual operations but also for MAPI.

I finally found the time at starting at 23:40 to answer your comment. First of all, I don't like your threatening (tell clients to move off TB) or insulting tone (from bug 1359418 comment #7: zero professionalism, etc.). You need to understand that TB is run by a community of unpaid volunteers, and indeed you don't have any entitlement to the software working or any bug being fixed. Please read the BMO etiquette linked at the bottom of the comment box. If you are a professional software provider "Rik Soft" with paying clients, you will understand the difference between free software and paid software and I encourage you to think about how easy it would be to get Microsoft or Apple to fix a bug. That said, let's take a look at the problem. In bug 1095629 we made the following change: When a Windows user used the context menu on a file "Send to > Mail recipient", that opened a HTML composition as per their current default account setting. So in that message, they could add bold, fonts, colour, etc. Sadly, the message was forced to plain text upon send and all the formatting was lost. That's why we made a small tweak, not to force the message to plain text: https://hg.mozilla.org/comm-central/rev/704f2187737b43831f4820f7e72cafa9ac574b71#l1.12 Switching that account to plain text and using "Send to > Mail recipient" opens a plain text composition and surely the resulting e-mail will be plain text. So far my testing. Looking at the code again, maybe the fix in bug 1095629 was wrong. So let me try to re-establish the previous behaviour while not regressing the problem we tried to fix.

Hi Aceman, I know you don't have Windows, but you can see that what I've done here is right. 1) I backed out the incorrect fix from bug 1095629. 2) I added a crash fix "Body.IsEmpty() ||" already found elsewhere in the file. 3) I fixed the problem from bug 1095629 correctly. Only we we use a compose window, we set the correct compose type, and then force "ForcePlainText" back to false. Without doing that, we could get default HTML composition which is later forced to plain text, which is bug 1095629. I tested it: "Send to > Mail recipient" still works, it opens a HTML or plain text window depending on the default, the HTML is not downgraded. So reporter, 0:30 here now, which professional you know will give you such great service?

Comment on attachment 8869619 [details] [diff] [review] 1366196-mapi.patch Review of attachment 8869619 [details] [diff] [review]: ----------------------------------------------------------------- ::: mailnews/mapi/mapihook/src/msgMapiHook.cpp @@ -799,3 @@ > // populate the compose params > pMsgComposeParams->SetType(nsIMsgCompType::New); > - pMsgComposeParams->SetFormat(nsIMsgCompFormat::Default); Note the silly duplicate SetFormat() here.

Comment on attachment 8869619 [details] [diff] [review] 1366196-mapi.patch Review of attachment 8869619 [details] [diff] [review]: ----------------------------------------------------------------- Thanks, let's hope it works ;) ::: mailnews/mapi/mapihook/src/msgMapiHook.cpp @@ +437,4 @@ > Body.AppendLiteral(CRLF); > > + // This is needed when Simple MAPI is used without a compose window. > + if (Body.Find("<html>") == kNotFound) Would StringBeginsWith(Body, NS_LITERAL_STRING("<html>")) work? @@ +641,5 @@ > if (NS_FAILED(rv)) return rv ; > if (Body.IsEmpty() || Body.Last() != '\n') > Body.AppendLiteral(CRLF); > > + // This is needed when Simple MAPI is used without a compose window. Bad indent. @@ +642,5 @@ > if (Body.IsEmpty() || Body.Last() != '\n') > Body.AppendLiteral(CRLF); > > + // This is needed when Simple MAPI is used without a compose window. > + if (Body.Find("<html>") == kNotFound) Would StringBeginsWith(Body, NS_LITERAL_STRING("<html>")) work?

https://hg.mozilla.org/comm-central/rev/ded5955bb94bfed1a60d951b6f11ce0ef0df2867 Thanks for the quick review. I fixed the indentation but I didn't want to mess with the HTML detection.

Comment on attachment 8869619 [details] [diff] [review] 1366196-mapi.patch [Approval Request Comment] Regression caused by (bug #): Bug 1095629. I'll get this into TB 52.2 quickly, even without a beta cycle to minimise the impact since I don't know whether we'll do another TB 54 beta.

https://hg.mozilla.org/comm-central/rev/ded5955bb94bfed1a60d951b6f11ce0ef0df2867 (comment #8) https://hg.mozilla.org/comm-central/rev/1893eb1abf794202865e66266f60540ba11dc01d (comment only) I landed a follow-up with some more comments pointing to the relevant bugs. I'm always undecided when it comes to putting bug numbers into the code, but I think in this cases it's warranted since this is a tricky/non-obvious problem, it's not covered by tests so far (bug 547027) and we don't want it to break again.

(In reply to Jorg K (GMT+2) from comment #3) > I finally found the time at starting at 23:40 to answer your comment. > > First of all, I don't like your threatening (tell clients to move off TB) or It was not threatening, I was only saying that we were left with only 2 choices: tell our customers to stay on an old version or use something else. To those that do not require our software I had/have no problem to suggest Thunderbird in any case even if you didn't fix the problem. > insulting tone (from bug 1359418 comment #7: zero professionalism, etc.). Sorry but you should also understand the other flip of the coin: it's not nice to wake up in the morning receiving 100 complaints against our software because, they say, "it is no longer working properly with the emails", especially because it was us that suggested the use of Thunderbird. So not only they get **** against us not understaning anything other than "Does not work", but we also had to downgrade everyone 1 by 1 and on more than 1 computer for each company. With zero professionalism I meant: before changing important behaviours of the software, think over, and think again before moving a finger, so not to damage millions of users. > You need to understand that TB is run by a community of unpaid volunteers, > and indeed you don't have any entitlement to the software working or any bug > being fixed. Please read the BMO etiquette linked at the bottom of the > comment box. Yes I know... apologies, but I hope you understand why people, especially programmers, could get a little-tiny-tad **** in such occasions! :-) (Especially knowing that Mozilla revenues are in excess of 160 millions per year and in 2011 Google Paid Mozilla 1 Billion for the next 3 years). Thanks everybody here for your job and in this occasion for the quick solution!

(In reply to Rik from comment #11) > (Especially knowing that Mozilla revenues are in excess of 160 millions per > year and in 2011 Google Paid Mozilla 1 Billion for the next 3 years). You have better info than us :) But then you surely know, that Thunderbird will not see a single cent from that "revenue" as it is financially separate and Mozilla is not putting any effort in TB. TB MAY indirectly get a smell of that money via Mozilla letting it run/be stored on its servers for some more months.

(In reply to Rik from comment #11) > (Especially knowing that Mozilla revenues are in excess of 160 millions per > year and in 2011 Google Paid Mozilla 1 Billion for the next 3 years). I can see that you are not well informed at all. In 2012 Mozilla withdrew all paid staff from the project and left it to unpaid volunteers. A few difficult years followed and in 2016 the Thunderbird team lead by the Thunderbird Council started picking up donations at a rate of $50K per month (you multiply by 12 and then compare with the figures you quoted). In November 2016 they hired their first part-time employee, me, to look after all the boring stuff, like continuous integration with Mozilla core software (used for Firefox) to guarantee Daily builds, etc. My job is also to spot regressions and fix them, which I did. I'm also the release manager for TB 52.x so I'll get this to your 100 complaining users within the next couple of weeks. Sadly, I don't do the release schedules. Light reading: https://blog.mozilla.org/thunderbird/ - Let me know if you need more info. As for the bug: It was sheer incompetence. We had a fix for bug 1095629 which had undesired side-effects. We don't have anyone on the team any more who knows this area well, so the regression happened. If you want to do yourself and your customers a favour I can only suggest this: Get onto the Beta program and test that your software still works with the upcoming TB release. This was broken since TB 51 beta (six weeks cycle) it was broken all through the TB 52 beta cycle (another six weeks) and got released broken. So you had 12 weeks to avoid those 100 angry calls. So if you now have to downgrade 100 users to TB 45, well, you know how you could have saved yourself the hassle ;-)

Beta (TB 54): https://hg.mozilla.org/releases/comm-beta/rev/a5bf14cc874a3dc026e97b1027593258ac6a4965 https://hg.mozilla.org/releases/comm-beta/rev/6128e9a93bf189ffa4a9abf11e9016578ae0e8bd

(In reply to Jorg K (GMT+2) from comment #13) > (In reply to Rik from comment #11) > > (Especially knowing that Mozilla revenues are in excess of 160 millions per > > year and in 2011 Google Paid Mozilla 1 Billion for the next 3 years). > I can see that you are not well informed at all. In 2012 Mozilla withdrew > all paid staff from the project and left it to unpaid volunteers. A few > difficult years followed and in 2016 the Thunderbird team lead by the > Thunderbird Council started picking up donations at a rate of $50K per month > (you multiply by 12 and then compare with the figures you quoted). Hi Jorg, sorry to hear that, I also read it in the news few days ago. Even if Mozilla is focusing on FF, I think it could be basically invisibile for them to invest 50000/year out of their millions on this piece of software that is one of the few remaining choices and the N.1 in the Linux + FOSS World. > In > November 2016 they hired their first part-time employee, me, to look after > all the boring stuff, like continuous integration with Mozilla core software > (used for Firefox) to guarantee Daily builds, etc. My job is also to spot > regressions and fix them, which I did. I'm also the release manager for TB > 52.x so I'll get this to your 100 complaining users within the next couple > of weeks. Sadly, I don't do the release schedules. Thanks again! > Light reading: https://blog.mozilla.org/thunderbird/ - Let me know if you > need more info. > > As for the bug: It was sheer incompetence. We had a fix for bug 1095629 > which had undesired side-effects. We don't have anyone on the team any more > who knows this area well, so the regression happened. No problem, it also happens with FF after all. Some months ago I reported this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1304637 and they weren't a little bit confused on what to do. :-) However reverting some changes avoided the problem to reach the stable branch. > If you want to do yourself and your customers a favour I can only suggest > this: Get onto the Beta program and test that your software still works with > the upcoming TB release. This was broken since TB 51 beta (six weeks cycle) > it was broken all through the TB 52 beta cycle (another six weeks) and got > released broken. > > So you had 12 weeks to avoid those 100 angry calls. So if you now have to > downgrade 100 users to TB 45, well, you know how you could have saved > yourself the hassle ;-) I'll surely do it from now on. I already am on the alfa channel with Firefox but I didn't think to do the same with TB because the only dangerous point for me is the Simple Mapi and I thought it was frozen. All the other features are not a problems even if overturned. Thanks again for everything, to you and the other guys around TB!

TB 52 ESR: https://hg.mozilla.org/releases/comm-esr52/rev/2182111f000d9060f199d1b3df72a405a02496e0

TB 52 ESR: https://hg.mozilla.org/releases/comm-esr52/rev/2182111f000d9060f199d1b3df72a405a02496e0 https://hg.mozilla.org/releases/comm-esr52/rev/bec98f8eb86f24195aac163c83eb7637374af6a9