bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

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




DOM: Core & HTML
15 years ago
15 years ago


(Reporter: Martijn Pieters, Unassigned)



Firefox Tracking Flags

(Not tracked)




(1 attachment)



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

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.


Comment 2

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

Comment 4

15 years ago
Boris is correct. Here is the JS Engine's escape() function
on the character '@', from the standalone JS shell:

js> escape('@');

Comment 5

15 years ago
Created attachment 113718 [details]
JS escape for @ symbol

As I see, JS escape return %40 to.
Ruslan, did you _read_ this bug?

Comment 7

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

Comment 8

15 years ago
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() -

Comment 9

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

Comment 10

15 years ago


    DOM Level 0. Not part of specification

And about DOM level 0 (from

  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

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?


Comment 11

15 years ago
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:


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

Not sure about cookie values.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs

Comment 14

15 years ago
With bug 44272, this was fixed as well.
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.