View Character Coding for message display broken

VERIFIED FIXED

Status

--
major
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: piskozub, Assigned: shanjian)

Tracking

({intl, regression})

Trunk
x86
Windows ME
intl, regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
cc to shanjian.
If 'override_charset' is set we should always use that charset. Shanjian, do you
think you changed anything around that?
Keywords: intl

Comment 2

17 years ago
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

Comment 3

17 years ago
*** Bug 107115 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 4

17 years ago
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 → ---

Comment 5

17 years ago
I see the problem with 10/26 build when viewing a Japanese mail which doesn't
have MIME charset info. 

Comment 6

17 years ago
2001-10-23-11-trunk does not have the problem, override works.
I will check 10/24 build.
Keywords: regression

Comment 7

17 years ago
It is broken in 2001-10-24-15-trunk.

Comment 8

17 years ago
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.

Comment 9

17 years ago
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.
(Assignee)

Comment 10

17 years ago
Created attachment 55584 [details] [diff] [review]
patch
(Assignee)

Comment 11

17 years ago
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
(Assignee)

Comment 12

17 years ago
Naoki, could you review my patch?

Comment 13

17 years ago
Comment on attachment 55584 [details] [diff] [review]
patch

r=nhotta
Attachment #55584 - Flags: review+
(Assignee)

Comment 14

17 years ago
Seth, could you sr?
(Assignee)

Comment 15

17 years ago
*** Bug 107458 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 17

17 years ago
fix checked in. 
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 18

17 years ago
Verified with 11/19 builds, it's fixed.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.