Closed Bug 192148 Opened 21 years ago Closed 21 years ago

ECMA-262 compliance: escape('@') should not escape

Categories

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

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mj, Unassigned)

References

()

Details

Attachments

(1 file)

ECMA-262 3rd ed. states that the at-sign should not be esacaped by the escape()
function, yet Mozilla's implementation does do this.

Tested on Windows and Linux, with 1.2.1 and a build from Jan 30 2003.
Reproducable: always

Steps:
type javascript:alert(escape('@')) in your browser location (or check out the
included URL).
Observe that escape('@') returns '%40'.

Expected result:
escape('@') should return '@'.

Reference: ECMA-262 3rd edition, paragraph B.2.1, step 7 (page 176).
Are you running this in the JS shell or in the browser?  The "escape" in the
browser is _not_ the same function as the JS "escape" -- it's a DOM function on
the Window object.

This is in a browser (the javascript: URL suggests this); are you saying that
the DOM lvl 0 escape function *should* escape '@'? IE 6 certainly doesn't.
No, I'm saying this is not a bug in the JS engine.
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → ashishbhatt
Boris is correct. Here is the JS Engine's escape() function
on the character '@', from the standalone JS shell:

js> escape('@');
@
Attached file JS escape for @ symbol
As I see, JS escape return %40 to.
Ruslan, did you _read_ this bug?
Okay, fair enough :)

Browsing through the JS source I indeed see both what appears to be a correct
implementation of the escape function (the IS_OK macro would indeed return true
for '@') and an #ifndef MOZILLA_CLIENT that removes the function from the
functions spec.

Still searching for the DOM lvl 0 implementation then.
Here is a reference to the ECMA-262 spec Martijn is referring to:
http://www.mozilla.org/js/language/  (see Edition 3 + errata link).

As Martijn points out, that specifies JS Engine's behavior here.
However, I don't know a reference for the spec on DOM's escape() -
Culprit: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsEscape.cpp#56

The first 0 should be a 7.

Compare this to: http://lxr.mozilla.org/seamonkey/source/js/src/jsstr.c#297

The latter file is the standalone version of escape. All we need to find out now
if the DOM lvl 0 version of escape is supposed to escape the '@' sign. For
reference: IE 6 does not escape it.
http://www.mozilla.org/docs/dom/domref/dom_window_ref19.html:

  Specification

    DOM Level 0. Not part of specification

And about DOM level 0 (from
http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html):

  The term "DOM Level 0" refers to a mix (not formally specified) of HTML
document functionalities offered by Netscape Navigator version 3.0 and Microsoft
Internet Explorer version 3.0. In some cases, attributes or methods have been
included for reasons of backward compatibility with "DOM Level 0"

The latter I had more or less forgotten; lvl 0 is not a standard, jsut the
implementations.

So, what did Netscape 4.x do? I no longer have access to a copy. :( I can only
assume the current behaviour is to provide backw3ards compatibility. If not,
could it please be changed to confirm to ECMA?

I am blind. Lines 57 and 58 of nsEscape.cpp give a motivation, albeit one I do
not agree with; escaping @ is not needed in either URL query strings nor in
cookie values.

The comment:

         /* bits for '@' changed from 7 to 0 so '@' can be escaped   */
         /* in usernames and passwords in publishing.                */

For ref, here's the relevant table again:

  http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsEscape.cpp#56

For our application we need '@' to *not* be escaped, and we were relying on ECMA
documentation telling us this was not to be escaped!
One issue is that the primary users of nsEscape are various URL-processing
utilities in Mozilla.  The fact that window.escape() uses it is somewhat
secondary.  So if nsEscape is not doing quite what window.escape() needs we may
have to add a "called from window.escape" flag or something....

URL query strings should handle _any_ character that's not a delimiter being
escaped...

Not sure about cookie values.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Depends on: 44272
With bug 44272, this was fixed as well.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: