22594 - [dogfood] JavaScript escape() is incompatable w/ 4.x

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Frank Tang]

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.

Comment 1

[Frank Tang]

Attachment: Japanese escape test cases

Comment 2

[Frank Tang]

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

Comment 3

[Frank Tang]

Attachment: same test cases w/ HTML

Comment 4

[Frank Tang]

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().

Comment 5

[Katsuhiko Momoi]

*** Bug 22595 has been marked as a duplicate of this bug. ***

Comment 6

[Katsuhiko Momoi]

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

Comment 7

[Katsuhiko Momoi]

Please include this in the Intl Browser check list for M13.

Comment 8

[Jim Roskind]

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

Comment 9

[Katsuhiko Momoi]

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().

Comment 10

[Katsuhiko Momoi]

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.

Comment 11

[leger]

Putting on PDT+ radar.

Comment 12

[Mike McCabe]

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.

Comment 13

[vidur (gone)]

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?

Comment 14

[leger]

per phil 0 Doesn't nsEscape replace netEscape bytes?

Comment 15

[vidur (gone)]

Implemented on 1/14/2000.

Comment 16

[Teruko Kobayashi]

Changed QA contact to [e-mail]
I verified this in 2000012008 Win32, Linux, and Mac build.