Closed
Bug 192148
Opened 22 years ago
Closed 21 years ago
ECMA-262 compliance: escape('@') should not escape
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mj, Unassigned)
References
()
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
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).
Comment 1•22 years ago
|
||
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.
Reporter | ||
Comment 2•22 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.
Comment 3•22 years ago
|
||
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•22 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•22 years ago
|
||
As I see, JS escape return %40 to.
Comment 6•22 years ago
|
||
Ruslan, did you _read_ this bug?
Reporter | ||
Comment 7•22 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•22 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() -
Reporter | ||
Comment 9•22 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.
Reporter | ||
Comment 10•22 years ago
|
||
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?
Reporter | ||
Comment 11•22 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:
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!
Comment 12•22 years ago
|
||
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.
Comment 14•21 years ago
|
||
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.
Description
•