Build: 10-10 branch and trunk build on all platforms. Steps to reproduce: 1. Launch browser and load non-ascii a. ftp server page, and b. http sever page, e.g.: A. ftp://10.169.114.243/ B. http://sakura.netscape.com - they are internal server page though. 2. In US build, the browser default charset is iso-8859-1, so both page are displayed garbled. 3. Manually select proper charset GB2312 for A and EUC-JP for B, then these two pages are displayed correctly. 4. Reload the page. Result: ftp server page A back to iso-8859-1 and display garbled while http server page B stay in EUC-JP. Another case is if I turn on auto-detector, the http server page B works fine but ftp server page A doesn't work also.
The only case works for ftp server is set up proper browser default charset. I think we should fix it, nominate as nsbeta1.
Keywords: intl, nsbeta1
QA Contact: ruixu → ylong
per i18n triage meeting: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
I think both roy and me are off mozilla for more than 2 years. If these bugs are still here now, I think the real stauts is 'won't fix'. If you want to reopen it, please find a new owner for it first.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
Mass Reassign Please excuse the spam
Assignee: tetsuroy → nobody
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
After 4 years this continues failing and nobody has taken seriously this bug, this is incredible!!
Makoto, will this be fixed by bug 26767?
(In reply to comment #8) > Makoto, will this be fixed by bug 26767? No. If we fix this, we have to add that it respects charset menu when generating HTML.
You need to log in before you can comment on or make changes to this bug.