I have attach a easy test case here. Try to view this w/ different encoding and compare w/ 4.x result. Notice the 2nd line are totaly different from 4.x. Try to view it with "Japanese (Shift_JIS)" or "wester (ISO-8859-1)"
Severity: normal → critical
*** Bug 22595 has been marked as a duplicate of this bug. ***
I corrected the URL to Netscape Japan Home Page. The US Home page does not use escape() function. This routine seems to be part of the International Netscape pages. If you want a Latin 1 page with this function, try: http://home.netscape.com/fr
Please include this in the Intl Browser check list for M13.
This is clearly a problem... and the PDT needs to understand how pervasive the impact is. It was mentioned that some search pages at Netscape are fine ('cause they don't use the escape() function). Can someone clarify the extent of the impact? Thanks, Jim
The impact seems to be the following: 1. Non-ASCII fails on NetCenter Chinese, Japanese and Korean pages because wrong string values are sent. 2. As far as I can tell, non-CJK Netscape Home pages don't seem to be failing with non-ASCII search. I tried French and German Home pages succeeded with non-ASCII string search. The difference between CJK and non-CJK Netscape International pages seem to be in the way the pages deal with 2 functions, i.e. function isBehaved() and function doSearch().
There were a few typos which make it difficult to understand what I werote, so let me try this again: The current known impact is: 1. Non-ASCII search fails on NetCenter Chinese, Japanese and Korean pages because wrong string values are sent. 2. As far as I can tell, non-CJK Netscape Home pages don't seem to be failing with non-ASCII search. I tried French and German Home pages and succeeded with non-ASCII string search. The difference between CJK and non-CJK Netscape International pages seems to be in the way the pages deal with 2 functions, i.e. function isBehaved() and function doSearch(). They are slightly different.
Putting on PDT+ radar.
Assignee: mccabe → vidur
I definitely need help on this one. I can easily set up window.escape() and window.unescape() (a la 4.x), but I need help with the implementation. The 4.x implementation makes use of the now-defunct NET_EscapeBytes and various INTL_ functions that probably have equivalents in the new world. What I'd love to be able to do is to set up the IDL and glue correctly, check in a stub implementation and just point someone at the place where the implementation needs to be provided. Any volunteers?
per phil 0 Doesn't nsEscape replace netEscape bytes?
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Implemented on 1/14/2000.
Changed QA contact to email@example.com I verified this in 2000012008 Win32, Linux, and Mac build.
Status: RESOLVED → VERIFIED
QA Contact: rginda → teruko
You need to log in before you can comment on or make changes to this bug.