User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007121615 Firefox/3.0b3pre (Swiftfox) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007121615 Firefox/3.0b3pre Previous builds of Firefox allowed overloading certain reserved words like "Namespace". This functionality is no longer available. Firefox 2.* and below support the following: alert(Namespace); -- returns "function Namespace() { [native code] }" function Namespace() { alert("My Code"); }; alert(Namespace); -- returns "function Namespace() { alert("My Code"); }" Firefox 3.* results in: alert(Namespace); -- returns "function Namespace() { [native code] }" function Namespace() { alert("My Code"); }; Error: redeclaration of const Namespace Source File: javascript:%20function%20Namespace()%20{%20alert("My%20Code");%20} Line: 1 This breaks compatibility with object namespacing/packaging mechanisms (like Ajile http://ajile.iskitz.com) Reproducible: Always Steps to Reproduce: 1. Attempt to overload by redeclaring function Namespace Actual Results: Error: redeclaration of const Namespace Expected Results: overloading of internal Namespace Digging through the sources for js 1.7 shows Namespace being declared with other reserved words in jsproto.tbl line 90: JS_PROTO(Namespace, 13, NAMESPACE_INIT) I assume this has to do with XML Namespace support. However this is does not appear to be a core feature of JavaScript (as yet), and should be reserved for use in XUL. Code running in the permission sandbox of a web page should be allowed to override this keyword.

It seems that making any global name that is not in ES3 as read only would inevitably breaks things.

Yes, I've been doing my homework since filing the bug. Please disregard my retardation with the comments on XML etc. I am unclear as to whether Firefox 3 is looking to ES4 as a guide. As awesome as that would be, this may perhaps create conflicts (esp with opinionated individuals like Pratap) in browser interop. I have to agree with Douglas Crockford in his opinion that the enforcement of reserved words (that have been pulled in from Java) should be relaxed. If ES3/4 makes no attempt to address the implementation of these reserved words what purpose do they serve going forward? This is perhaps better addressed in ES4 (or if there is to be a TR .. a 3.1) but would it be possible to implement some of these relaxations in the Mozilla machine?

Bug 407323 comment 5 is related. (Also read bug 376957, which this bug blocks.)

This also affects the "Date" object, which, in particular, breaks the popular FogBugz app (http://www.fogcreek.com/FogBugz/ ; you need to sign up for a trial, log into your trial instance and try modifying bugs to actually experience the brokenness). I suspect there are other sites/apps out there that do this kind of thing, so nominating for blocking 1.9.

good.midget: reserved words are now (since JS1.7, in Firefox 2, based on proposed ES4 specs) reserved only in non-property-name contexts, but this is a completely separate issue from Namespace's binding being read-only and don't-delete in the global object. Namespace, the global property, is not a reserved word. You can shadow it in a function with an inner function name or var declaration, e.g. This bug is good evidence against making Namespace read-only (and don't-delete -- RO without DD is pointless) without explicit version selection. Indeed, that is what ES4 proposes -- not what we did in the patch for bug 376957. From the ES4 Reference Implementation, builtins/Namespace.es: __ES4__ final class Namespace { . . . } What's more, bug 376957, ostensibly about JSON integrity for defense-in-depth (if a site fails to authenticate properly), made two changes: one was to construct object and array initialisers using memoized initial values of global constructor properties; the other was to make the standard constructor properties RO+DD in the global object. At this point, it seems we are only breaking extant JS by doing the latter, and we should revert to requiring opt-in versioning to make immutable "type name" bindings. That fits ES4's requirements for sound type checking, and leaves ES3 as it was. Cc'ing Lars. I'm going to clean up this bug's summary and take it to fix for the next Firefox 3 beta release. Thanks, /be

Sorry, bugzilla still loses some stuff on mid-air collisions (not Cc: additions). /be

I threw in a couple of comment nit-picks in the tree I used for this patch, hope that's ok. /be

The overloading of the Date constructor came up as a concern on my blog, as well (Zvents is used by major sites like boston.com): http://ejohn.org/blog/re-securing-json/#comment-296268

Fixed: js/src/jsapi.h 3.169 js/src/jsarray.c 3.138 js/src/jsbool.c 3.33 js/src/jscntxt.c 3.125 js/src/jsdate.c 3.95 js/src/jsfun.c 3.245 js/src/jsnum.c 3.93 js/src/jsobj.c 3.409 js/src/jsregexp.c 3.174 js/src/jsstr.c 3.180 js/src/jsxml.c 3.182 /be

tests updated in bug 407323 comment 11 e4x/Regress/regress-407323.js js1_5/Regress/regress-407323.js

verified fixed 1.9.0

Actually, I DUPED 412324 to here, but this patch doesn't seem to have any love for Error. Should it?

Error must've gotten fixed elsewhere; if someone can aim me that way, I will dupe 412324 elsewhere.

crowder, see bug 412324 comment 12