(Moved over from http://bugscape.netscape.com/show_bug.cgi?id=3019) Steps to reproduce: 1) Load a KO or CH page (e.g. URL above) in JA 10-13-08-MN6(Win32). 2) Select EUC-KR (not Auto-Detect) from CharCoding menu to display the page. * EUC-JP and JA Auto-Detect are left on as they were (default). 3) Click any picture/image or text link to jump to another page. 4) Click Back button to return to the home page loaded. ==> The newspaper home page is displayed in garbage again since the selected encoding (EUC-KR) is not retained with cached page. CharCoding reverts to EUC-JP on the cached copy. Happens only in JA bld, and NOT in US 10-13-08-MN6(Win32). ------- Additional Comments From email@example.com 2000-10-31 15:17 ------- I don't see the problem. Is it still valide for 1030 build? ------- Additional Comments From firstname.lastname@example.org 2000-10-31 16:16 ------- Still happens in JA 10-30-09-MN6. ------- Additional Comments From email@example.com 2000-10-31 16:31 ------- This turned out to be an I18n problem. The reason why it didn't happen in US bld was that Auto-Detect is off as default in US bld. As soon as an Auto-Detect was on US 10-30-09-MN6 exhibited the same problem. Editing Summary and re-assining.
reassigning to shanjian per bobj.
According to momoi, this is the correct behavior: CharCoding info is retained in cached copy, but Auto-Detect takes precedence and overrides it. If this is correct, please resolve this as WorksForMe.
move all cata's bug to ftang
reassign to shanjian
Changing QA Contact to ylong.
Yes, this is the right behavior. Users tend to think that cache charset should override autodetecting result, but that have one problem that we do not have an easy fix yet. If user visit some page and find that the page is not in right encoding, he may choose an autodetector to try it again. If we let charset in cache has high priority, this newly chosen autodetector will not work.
Mark as verified. Also with both 6.01-ja RTM and recently trunk build, I couldn't see this problem on WinME-ja.