Closed Bug 465586 Opened 13 years ago Closed 13 years ago

forwarding inline base64 breaks non-English codepage

Categories

(MailNews Core :: MIME, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b1

People

(Reporter: ezh, Assigned: Bienvenu)

References

Details

(Keywords: regression, Whiteboard: worst case, we'll back out fix for bug 307023)

Attachments

(2 files)

1. Load some base64 mail in non-Western codepage.
2. Forward it as inline.
3. The non-Western characters are broken. Cyrillic is not readable at all.

For example Estonian word: Müüja = M=C3=BC=C3=BCja. Russian is forwarded in that way: =D2=CE=CB=DC=CA=CE.

When the mail is complete base64, the it is forwarded as code:
0J/RgNC40LLQtdGC0LjQuiwg0JbQtdC90YwuDQoNCtCQINGN0YLQviDQtdCy0YDQvtCy0YvQuSDR...


First seen in TB20081112.
Likely related to the fix for bug 307023, based on appearance and timing.
Can you verify that the 20081111 build was still ok?
20081111 is fine.
Blocks: 307023
Keywords: regression
Can you attach a sample message, thx!
I'd like to, but after recent crash half an our ago Tb wont't start anymore. Fresh install (tried latest builds as well) does not helps, new profile does not hepls...

24-27Mb in mem and notning happends...

:-/
Attached file example
Here is a .msg. Only text is in message.
Is this sample OK?
yes, thx, I'm able to test with this.
I'll try to find a way to fix this w/o regressing bug 307023
Assignee: nobody → bienvenu
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b1
Component: General → Composition
OS: Windows XP → All
Product: Thunderbird → MailNews Core
QA Contact: general → composition
Hardware: PC → All
it's really a mime bug - if I can't fix this, the fix for bug 307023 will need to be backed out.
Assignee: bienvenu → nobody
Component: Composition → MIME
QA Contact: composition → mime
Assignee: nobody → bienvenu
Whiteboard: worst case, we'll back out fix for bug 307023
Attached patch proposed fixSplinter Review
I think that in the case of drafts, the mimeleaf code doesn't need to go through the decoder, since the higher level mime objects, like mimemrel.cpp, or mimemsg.cpp will go through the decoder. But I don't have a high degree of confidence in this...it does fix the various test cases I have, including the things that regressed with the previous patch. I'm pretty sure this patch will still only affect drafts/templates/forward inline, but my inclination is probably to go with backing out bug 307023 's fix, and trying out this fix early in the beta 2 cycle, but I'm open to suggestions.
Attachment #349918 - Flags: superreview?(neil)
Attachment #349918 - Flags: review?(bugzilla)
Just thinking about this, we have this bug and bug 464969 which both appear to be regressions from bug 307023 and I'm guessing more visible. The original target for bug 307023 was beta 2 (before we added the extra alpha).

My inclination would be to back out bug 307023 for beta 1 (as you say) and then land the patch again, and maybe this patch at the start of beta 2 so we can get longer testing coverage with nightly testers.

Do you think it may be possible to hook up unit tests for this? I know some of it is what ends up on the display, but I'm wondering if we can hook the streams into unit tests somehow. This could give us a better understanding/confidence that future fixes will work/not regress.
I was thinking we were going to have to do mozmill tests for these problems, but maybe there's some way of using a stream listener, and coercing the mime type - nsMsgComposeService::LoadDraftOrTemplate has some relevant code.
fixed by backing out bug 307023 - I'm going to move this patch over to that bug.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 349918 [details] [diff] [review]
proposed fix

Cancelling review requests for the time being...
Attachment #349918 - Flags: superreview?(neil)
Attachment #349918 - Flags: review?(bugzilla)
You need to log in before you can comment on or make changes to this bug.