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)
MailNews Core
Composition
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.9.1b2
People
(Reporter: philor, Assigned: philor)
References
Details
Attachments
(1 file)
632 bytes,
patch
|
Bienvenu
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter 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+
Updated•16 years ago
|
Attachment #345919 -
Flags: superreview?(bienvenu)
Attachment #345919 -
Flags: superreview+
Attachment #345919 -
Flags: review?(bienvenu)
Attachment #345919 -
Flags: review+
Comment 1•16 years ago
|
||
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...
Assignee | ||
Comment 2•16 years ago
|
||
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.
Description
•