When you browse the page which does not have meta tag and set the charset coding in browser and try to edit the page in Composer, the character coding is not same as Browser. Steps of reproduce 1. Open Navigator 2. Go to http://www.yahoo.co.jp/ 3. Select menu View|Character coding->Japanese(EUC-JP) 4. Select menu File|Edit page In the Composer, the Japanese characters are not displayed correctly. Japanese (EUC-JP) should be set in Composer. Tested 2000-07-12 build.

Reassign to ftang.

nsbeta3- per i18n bug meeting. Thsi may be fixed partially by 21313. Teruko should check 4.x behavior. Even we don't fix it, we don't think user will hit this .

This works fine in 4.x. Composer remembers the charaset in browser.

Added intl and nsbeta1 keywords.

Changed QA contact to ylong@netscape.com.

composer bug. mark this as moz0.9 and reassign to yokoyama.

Roy/Ftang - Can we get this fixed for M0.9.1

www.yahoo.co.jp works now (yahoo added server charset). Use www.kinokuniya.co.jp to reproduce the bug.

I guess this bug has 2 issues: 1. Page can not display correctly 2. Correct Charset in Browser has not been set in Composer. So for Yahoo-Japan, there is charset in their server, when you bring this page to Composer, the page will display correctly, however, there is no correct charset has been marked in Composer so that when you save the page to a file and re-open it, it won't display correctly. And for www.kinukuniya.co.jp - it doesn't display correctly and charset was not marked to shift-jis neither.

Yuying Long : I don't think we have two issues here. Only one!! You issue #1 is correct behaviour when you have the Auto-detect OFF (by default). I see www.kinukuniya.co.jp gets displayed correctly when you have the Auto-Detect ON.

teruko: Is this duplicate of 45408?

Teruko: sorry I meant 77229.

Changed URL.

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

I mark 77229 as dup of this bug since this is found earlier.

Please have a look. Thanks

I've looked into the JS window handlers a week ago in my local build and they appeared to extract and pass the document charset into new browser instances correctly. I recall a time, when the JS handlers got broken by some other changes in the product, but that seems no longer to be the case. I just spoke to Yuying about some related issues, which should be addressed for 0.9.1. I just re-tested with the 0.9 Mozilla release and it seems to work there... Please make sure that you clear your disk and memory cache (Preferences->Advanced->Cache) and remove any bookmarks referring to the page, when testing this. Mozilla pulls the charset info from many sources, cache and bookmarks are among them, which might not be immediately transparent.

teruko, could you please see, whether this works for you in the latest build? I think the problem went away. I just checked a few things in my private build and I might want to put in a little modification, but if it works for you now I might bump this bug to 1.0.

I tested this in 2001050804 Win32 build. This works fine. I found the problem if the page has meta charset. - bug 79735

moving to 1.0

0508 Win32 trunk build on Win2k-CN: 1. For he original report page: http://www.yahoo.co.jp/, it will display fine in Composer when you select EUC-JP in browser first, however, the problem is charset EUC-JP has not been marked in Composer when View | Character Coding. 2. For the page that changed in URL field: http://babel/tests/editor/charsetmenu/Selected_data_west_sjis.htm I was not seeing it display correctly in Composer, the charset Shift-JIS has not been marked as well.

Yuying, it appears that http://babel/tests/editor/charsetmenu/Selected_data_west_sjis.htm is also mislabeled as Latin-1. Teruko open a new bug for handling of mislabeled pages in composer - bug 79735. The checkmark drawing problem will take some time to fix, since we are waiting on Waterson (bug 78290) and there is another problem with the composer menu - bug 39780, where the new entries don't get added to the menu and subsequently can't get check marked.

I believe this works now as expected. Since we have a new bug (bug 79735) for the changes I wanted to make to the composer charset handling, I'll go ahead and close this.

I'll mark it as verified.