the escape() function in JavaScript produce different result than 4.x. This cause Netscape home page search malefunction when user type in non-ASCII data.

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)"

When I load the test cases w/ 4.x under "Japanese (Shift-JIS)" the 2nd line is %93%FA%96%7B%8C%EA When I do the same thing in SeaMonkey, it is %u65E5%u672C%u8A9E This bug cause Netscape search fail to handle non ASCII. In the other hand, there are no problem w/ search page which do not use JavaScript escape().

*** 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.

Sounds like something we thrashed over extensively in 4.x when our internal string representation went from being the same as that of the incoming encoding to a Unicode representation. Clients of escape() (servers) still expected to see strings in the encoding, so trouble ensued. Mike McCool (with much hair-pulling) reimplemented the escape and unescape functions to be aware of the current document encoding, and use that encoding when computing the results of the escape and unescape functions. Just applying %20 (or whatever) escaping to the decode Unicode characters doesn't cut it. The escape and unescape functions have always been implemented as part of the DOM, not as a core JavaScript function. (There's an 'escape' implemented in the JavaScript function for ECMA conformance, but it should be overridden in the browser.) Unfortunately, I can't find the implementations just now; reassigning to the DOM component in the hopes that someone there knows Please feel free to ask me for more about the history of these functions.

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?

Implemented on 1/14/2000.

Changed QA contact to teruko@netscape.com I verified this in 2000012008 Win32, Linux, and Mac build.