107084 - View Character Coding for message display broken

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect)

Description

[Jacek Piskozub]

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

[nhottanscp]

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

Comment 2

[nhottanscp]

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.

Comment 3

[nhottanscp]

*** Bug 107115 has been marked as a duplicate of this bug. ***

Comment 4

[Shanjian Li]

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. 

Comment 5

[ji]

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

Comment 6

[nhottanscp]

2001-10-23-11-trunk does not have the problem, override works.
I will check 10/24 build.

Comment 7

[nhottanscp]

It is broken in 2001-10-24-15-trunk.

Comment 8

[nhottanscp]

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

[nhottanscp]

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.

Comment 10

[Shanjian Li]

Attachment: patch

Comment 11

[Shanjian Li]

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. 

Comment 12

[Shanjian Li]

Naoki, could you review my patch?

Comment 13

[nhottanscp]

Comment on attachment 55584 [details] [diff] [review]
patch

r=nhotta

Comment 14

[Shanjian Li]

Seth, could you sr?

Comment 15

[Shanjian Li]

*** Bug 107458 has been marked as a duplicate of this bug. ***

Comment 16

[(not reading, please use [e-mail] instead)]

Comment on attachment 55584 [details] [diff] [review]
patch

sr=sspitzer

Comment 17

[Shanjian Li]

fix checked in. 

Comment 18

[ji]

Verified with 11/19 builds, it's fixed.