** Observed with 11/8/2000 Win32 MN6 build ** The problem was discoverd while checking on a Japanese localized version of NS6. But you can re-create this in an English build. 1. Set the Edit | Pref | Mailnews | Startup page to http://messenger.netscape.com/ja/messenger/6/start/index.html or any Japanese page which has a meta charset tag. 2. Now open startup Mozilla and open Mail. If you have selected the startup page to come up, this is where you will see the above page. At this point, it displays OK as Japanese. 3. Select a serve and Inbox. At this point, don't select any message yet. 4. Now engage the menu,"GO | Mail startup page" (or something like this wording). 5. This will display the startup page in the viewing window. At this point, it should display OK. 6. Now select a message -- any message will do. 7. Then engage the "GO | Mail startup page" menu again. 8. You will see that the page is no longer displayed as readable Japanese. 9. Confirm that there is no way to correct this -- choose View | Character Coding | More | East Asian | Japanese (Shift_JIS). This latter action realods the message but not the page. From all of this, it seems that we are incorrectly applying the charset context from the selected message to the web page being loaded. The other problem is that the meta-charset tag in the web page is not honored here.

Added intl and major keywords. This bug affects Messenger startup page display if the user opts to engage "GO | Mail startup page" while a message is selected.

QA contact to marina.

marking nsbeta1- due to infrequency of using the menu item.

The mail startup page is also displayed garbled when the user adds a new mail/news account with mail start up page pointing a web page in a different encoding with the mail that the user is currently viewing. Steps to reproduce: 1. Have mail startup page set to http://home.netscape.com/ja 2. View a Japanese ISO-2022-JP mail. 3. Select Edit | Mail/News account settings to bring up mail/news account setup wizard. 4. Add a new mail/news account. 5. After the wizard is finished, select the inbox or newsgroup of the new added acount on 3-pane. You'll see the mail start page is garbled in message view pane. Since ISO-2022-JP encoding is commonly used for Japanese mails and Shift-JIS is commonly used for web pages in Japan, the user will be very likely to get this problem when setting up multiple mail/news accounts.

Nominating for nsbeta1. It garbles the mail startup page and reduces the user visit numbers to that page.

Great work, xianglan. This bug is now much more important than before because it will show up as a porblem every time the user creates a new mail account. Let's see if we cannot include this in the nsBranch.

I think if we want to fix this that we will need some I18N help. Is there someone who can help out?

I tried a workaround for the Japanese Messenger startup page. That is, putting the page in the same encoding as the Japanese mail encoding and it does not work! I tried te French/Latin 1 Home page when viewing a Latin 1 message and the accents display corrupted. As the matter stands, the new account creation will expose this ugly problem for all non-ASCII script languages. That will include French, German, and all other Western languages, Central European languages, CJK,etc. From the looks of it, we might be assuming that the page coming in is in Unicode except when the page loads upon the first mail account creation.

Naoki, Can you take a look and consult on this bug? This is an ugly one.

Message display uses UTF-8 internally. The message view area is initialized to UTF-8 when the user clicks to see the first message. After that, non ASCII start up pages cannot be seen correctly because the charset attribute is fixed to UTF-8 for the view area. Possible solution/workaround: * Mail client to reset the UTF-8 charset attribute before loading the start up page then restore it to UTF-8 after the loading. * Feed the start up page through libmime so it is automatically converted to UTF-8. * Turn off the start up page for localized builds. * Netcenter to generate UTF-8 start up page. I am not sure about exact risk and cost of them but it does not seems to be a low risk. Also, those changes may break non ASCII message view (e.g. reset the UTF-8 attribute causes all non ASCII messages unreadable), so this should be very carefully done.

Naoki, can you tell us why: * Feed the start up page through libmime so it is automatically converted to UTF-8. would not be a better solution than others in this case? How does this start-up page initially load OK if it is not going through normal libmime path?

I am not saying that is not a better solution. I don't know about the detail implementation. But I assume that the UTF-8 attribute is set when the user clicks to see the first message that happens after the initial start up page load.

I am summarizing now the conditions which will cause this problem for all non-ASCII languages: 1. When engaging "Go | Mail Start Page" after you have viewed at least one message in that folder. 2. When creating an additional mail account after having viewed a msg in an existing accoun, at the initial login to the new account, the start up page is displayed with unreadable garbage. 3. (New type) After Viewing a msg in one account, if you try to login into another which asks for the password, because no msg is selected, it will bring in the Msg start page. But since you already viewed a msg in another account, the start up page in the 2nd account is garbled. If you then move to a third account, you will have the same problem, etc. In other words, if you have set up to giev password to multiple account, only at the first account, you will see the page correctly. The same page in all other accounts will display garbled. I think there are too many types of cases for this problem to be ignored now. I strongly reecommend that we fix this in the 0.9.2 branch.

can we work around this bug by using NCR in ISO-8859-1 page?

> can we work around this bug by using NCR in ISO-8859-1 page? Theoretically we can but not practical. The start-up page is not satic and it gets updated. The client development team does not control how the content is prepared. I doubt if we can do much here. I recommend fixing this for the final Netscape version. This is a very ugly problem.

Are we anywhere near fixing this problem? Do people understand how pervasive this problem is and how bad does it look every time the user logs into anything other than the main account when non-ASCII language page is the start-up page? There are 2 other ways in which the user encounters this problem. I am surprised that the L10n team is not asking for a fix.

Selected as one of the top 3 intl. bugs for eMojo mail

putting into the .9.4 milestone

Ok, I'm on a mission to stamp out our I18N bugs for .9.4 tonight. I have a fix for this coming up.

r=naving

sr=sspitzer

this is now fixed.

will be able to verify in the next ja build, leaving now as fixed

This can be verified by changing the URL to a non-ASCII web site (like http://home.netscape.com/ja) from preference setting on an English build. It's fixed on 08-22-08-trunk build.

the bug is fixed ( setting mail default page at launch to home.netscape.com/ja) the display is correct