1.86 KB, text/plain
***observed with 2001-01-19-06-mtrunk win32 build***** Sometimes, the charset for a mail doesn't have its own charset marked on the charset menu, it has the charset of previously selected mail marked. Steps to reproduce: 1. Download and unzip the smoketest folder on the above URL. 2. Have a mail that has incorrect charset info in the body. I'll attach the mail later. This mail has iso-2022-jp contents, but incorrectly labeled as iso-8859-1. 3. Select the incorrectly labeled mail first, select View | Character Encoding menu, you'll see Western (iso-8859-1) is marked on the left. 4. Go to the smoketest folder, select 2nd mail, which is an iso-2022-jp mail. Select View | Character Encoding menu, you'll see Japanese (iso-2022-jp) is marked for this mail. 5. Go back to the incorrectly labeled mail, select View | Character Encoding menu, you'll see the charset marked for the mail doesn't change to iso-8859-1, it stays as iso-2022-jp. It doesn't looks like a cache problem, since at Step 4, the 2nd mail in the smoketest folder has correct charset marked even you select the incorrect labeled mail first.
i think this is the case of cache update that was raised in # 61285
I wonder if it's a cache problem, why it can always have right charset marked for the mails in the smoketest folder.
Added intl keyword.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8
messages in smoketest folder ( smoketest.zip) are MIME encoded, messages that inherit the previous charset has no MIME info.
The testcase I attached has wrong MIME charset info.
right, that's why it never happens in the smoketest folder where the MIME label is correct
I think this is fixed now, I cannot reproduce it with today's build (win32 id 2001020504).
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Verified with 04/02 build.
You need to log in before you can comment on or make changes to this bug.