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

VERIFIED FIXED

Status

()

Core
DOM: Core & HTML
P3
critical
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Frank Tang, Assigned: vidur (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], URL)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
Created attachment 3801 [details]
Japanese escape test cases
(Reporter)

Comment 2

19 years ago
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)"
(Reporter)

Comment 3

19 years ago
Created attachment 3802 [details]
same test cases w/ HTML
(Reporter)

Updated

19 years ago
Severity: normal → critical
Summary: JavaScript escape() is incompatable w/ 4.x → [dogfood] JavaScript escape() is incompatable w/ 4.x
(Reporter)

Comment 4

19 years ago
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

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

Comment 6

19 years ago
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

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

Comment 8

19 years ago
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

19 years ago
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

19 years ago
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.

Updated

19 years ago
Whiteboard: [PDT+]

Comment 11

19 years ago
Putting on PDT+ radar.

Updated

19 years ago
Assignee: mccabe → vidur
Component: Javascript Engine → DOM Level 0

Comment 12

19 years ago
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.
(Assignee)

Comment 13

19 years ago
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

19 years ago
per phil 0 Doesn't nsEscape replace netEscape bytes?
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

19 years ago
Implemented on 1/14/2000.

Comment 16

19 years ago
Changed QA contact to teruko@netscape.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.