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.
No, I'm saying this is not a bug in the JS engine.
Assignee: rogerl → jst
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('@'); @
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 firstname.lastname@example.org
Assignee: jst → dom_bugs
With bug 44272, this was fixed as well.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.