From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5+) Gecko/20011026 BuildID: 2001102609 A message is displayed using the message coding it has in header ignoring both View -> Character Coding and View -> Folder Characrter Coding settings (if other than ISO-8859-1). This seems to be a recent regression. I notice it in newsgroups with Polish postings which have ISO-8859-1 or no character coding in header (should be ISO-8859-2). There is presently way now to make them rendered in ISO-8859-2 even as I have this setting both in preferences for message display and in the newssgroup settings. It used to work fine until recently. Marking major as this is a big problem to non-ISO-8859-1 countries.
cc to shanjian. If 'override_charset' is set we should always use that charset. Shanjian, do you think you changed anything around that?
I tested 10/27 trunk build and this is broken. 1) In the i18n smoke test, select the second Japanese message. 2) Change character coding to Western. 3) It still shows Japaense. If the override works it should show raw ISO-2022-JP strings. Shanjian, could you try this on your build and check what's broken? I will also look at this when my build is done.
Assignee: nhotta → shanjian
Target Milestone: --- → mozilla0.9.6
*** Bug 107115 has been marked as a duplicate of this bug. ***
Naoki, it doesn't look like my problem. In "MimeInlineText_initialize" line "obj->options && obj->options->override_charset", obj->option is null. You might need to find out why is that. I believe "obj->option" should not be null, and "obj->options->override_charset" should be set to the override charset.
Target Milestone: mozilla0.9.6 → ---
I see the problem with 10/26 build when viewing a Japanese mail which doesn't have MIME charset info.
2001-10-23-11-trunk does not have the problem, override works. I will check 10/24 build.
It is broken in 2001-10-24-15-trunk.
Shanjian, I locally backed out your changes of mimetext.cpp, mimetext.h and mimemsg.cpp, then override is working. I think it's somehow related to your change, please take a look at it.
The default charset used to be set at MimeInlineText_rotate_convert_and_parse_line before the change. That part of the code was removed by the change.
The problem of this bug is because obj->option and obj->header is not set when "MimeInlineText_initialize" is called. To set obj->option and obj->header does not look like a good option. It has great impact on all mime object implementation. I move this charset initialization code to function "MimeInlineText_rotate_convert_and_parse_line", and added a variable to indicate either this initialization happened or not. We don't want to do it more than once. There is another advantage of this approach. When " if ( (obj->options && obj->options->charset_conversion_fn) && (!obj->options->force_user_charset) && (doConvert) )" is not true, this initilization will not be necessary and thus can be avoided.
Status: NEW → ASSIGNED
Naoki, could you review my patch?
Comment on attachment 55584 [details] [diff] [review] patch r=nhotta
Attachment #55584 - Flags: review+
Seth, could you sr?
*** Bug 107458 has been marked as a duplicate of this bug. ***
Comment on attachment 55584 [details] [diff] [review] patch sr=sspitzer
Attachment #55584 - Flags: superreview+
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified with 11/19 builds, it's fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.