27454 - This page is loaded as blank when charset is set to Shift_JIS

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Teruko Kobayashi]

When you set Character set menu to Shift_JIS and go to the page, the page is loaded as blank.

Steps of reproduce
1. Launch Seamonkey
2. Change Character set menu to Shift_JIS
3. Go to above URL

The page is loaded as blank.

If you change Character set menu to something other character set, Western or Japanese (ISO-2022-JP), the page will
be loaded correctly.

Tested 2000021108 Win32 and 2000021111 Linux build.

Comment 1

[Frank Tang]

assign as M16. 

Comment 2

[Frank Tang]

This is because when we set the default charset to a multibyte but 
incorrect charset, we convert the byte into PRUnichar and may *eta* some tag, 
after that, the parser won't parse the META tag correctly and our meta tag 
observer will never get the meta tag notification to figure the real one. 
Solution, put some byte based (instead of PRUnichar based) scanning code as cxue 
did in the PeekMetaCharset function in 2.0. Put into the parser and run for the 
first block as we currently did for the xml encoding. 
This bug only happen if there are non ASCII before the META tag. 
Add harishd to this bug.

Comment 3

[Frank Tang]

should consider bug 26651 when we decide our plan.

Comment 4

[Frank Tang]

charset handling and converter related issue. REassign to cata and cc jbetak.

Comment 5

[leger]

Putting on [nsbeta2-] radar.  Not a stop ship for PR2.

Comment 6

[Frank Tang]

*** This bug has been marked as a duplicate of 25037 ***

Comment 7

[Frank Tang]

I am stupid. This is a different bug.

Comment 8

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 9

[Frank Tang]

move all cata's bug to ftang

Comment 10

[Frank Tang]

mark this as moz0.9

Comment 11

[Frank Tang]

shanjian- can  you help to look at this?

Comment 12

[Shanjian Li]

I could not reproduce the problem. I did try to 
move title which contains some multibyte character before meta tag. It is very likely 
that the fix in 64235 prevent us from eating additional "<" when meet illegal multibyte
sequence, and thus prevent the problem from happening. Both "<" and ">" are not legal 
part of SJIS 2-bytes character.

I would resolve this bug as fixed (by 64235). I will post a test case for QA verification.
Please use a build before 03/12 to reproduce the problem. 

Comment 13

[Shanjian Li]

Attachment: test case to reproduce the problem

Comment 14

[Shanjian Li]

Resolve the bug as fixed. The fix is in 64235 which has been checked in.

Comment 15

[Yuying Long]

Fixed verified on 03-29 trunk build.