Closed Bug 462725 Opened 16 years ago Closed 16 years ago

MDN fails to encode subject until after an email has been sent

Categories

(MailNews Core :: Composition, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9.1b2

People

(Reporter: philor, Assigned: philor)

References

Details

Attachments

(1 file)

Attached patch Fix v.1Splinter Review
(Followup to bug 335534, particularly bug 335534 comment 27) This is somewhere between evil and silly, but... STR: 1. Send yourself two emails with a return receipt requested, but don't read them. 2. Open a Thunderbird in a language which has the MDN strings translated, but which doesn't cheat and QP encode them in the .properties file, so not de or fr, but lt is a good choice. 3. *Without* first sending an email, select one, say OK (Gerai) to send the return receipt 4. Compose and send an email. 5. Select the other one, say Gerai to send the return receipt. 6. View Message Source on each of your return receipts Expected: The subject in both will be mime encoded, "Gavimo =?UTF-8?B?cGHFvnltYSAobGFpxaFrYXMgYXR2ZXJ0YXMpIC0g?=" Actual: The first one will be raw UTF-8, "Gavimo pažyma (laiškas atvertas) -" and the second will be encoded. The problem is that we determine whether or not to encode in http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#495 based on compUtils->GetMsgMimeConformToStandard, but that's actually just the long way to call nsMsgMIMEGetConformToStandard in http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompUtils.cpp#162 and as you can see from that, you only Get what you previously Set, and if you didn't Set anything, you get PR_FALSE. (There should be another amusing set of steps, where you set mail.strictly_mime_headers to false, which should mean that you won't encode the subject, then set s/mime to always encrypt, send an email, and then send a return receipt, which will mime encode the subject despite your pref saying not to do so, since the compose init for a message that's going to require encryption work ignores the pref and sets mime_headers_use_quoted_printable_p to true, though that one's likely to require more work mucking with certs, and for all I know will encrypt the return receipt, which takes away the amusement since it then *needs* to ignore the pref.) There might be a solution that's beyond me, which involves doing something prettier, but what works is just to say that since we default mail.strictly_mime_headers to true, it makes sense to init mime_headers_use_quoted_printable_p to true, too, so that anyone like MDN who calls it without first setting something will get what it mostly likely would get if it did set something first.
Attachment #345919 - Flags: superreview?(bienvenu)
Attachment #345919 - Flags: review?(bienvenu)
Flags: wanted-thunderbird3+
Attachment #345919 - Flags: superreview?(bienvenu)
Attachment #345919 - Flags: superreview+
Attachment #345919 - Flags: review?(bienvenu)
Attachment #345919 - Flags: review+
Comment on attachment 345919 [details] [diff] [review] Fix v.1 thx for the explanation, Phil. A comment in the code might be helpful, I guess to the effect that that static bool should track the value of the pref...
Pushed in http://hg.mozilla.org/comm-central/rev/4bdaec3f9fd6 with the comment I should have thought to add.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: