Closed Bug 409252 Opened 17 years ago Closed 17 years ago

Date, Namespace, etc. constructors can no longer be overwritten


(Core :: JavaScript Engine, defect)

Not set





(Reporter: good.midget, Assigned: brendan)



(Keywords: regression)


(1 file)

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

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.
Blocks: 376957
Ever confirmed: true
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 ( ; 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.
Severity: normal → major
Flags: blocking1.9?
Keywords: regression
Summary: Reserved word "Namespace" can no longer be overloaded → Reserved words ("Namespace", "Date", ...) can no longer be overloaded
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/

    __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,

Assignee: general → brendan
Severity: major → normal
Keywords: regression
Summary: Reserved words ("Namespace", "Date", ...) can no longer be overloaded → Reserved word "Namespace" can no longer be overloaded
Blocks: js1.8
Flags: blocking1.9? → blocking1.9+
Summary: Reserved word "Namespace" can no longer be overloaded → "Namespace" property of global object can no longer be overwritten
Summary: "Namespace" property of global object can no longer be overwritten → Date, Namespace, etc. constructors can no longer be overwritten
Target Milestone: --- → mozilla1.9 M11
Sorry, bugzilla still loses some stuff on mid-air collisions (not Cc: additions).

Severity: normal → critical
Keywords: regression
I threw in a couple of comment nit-picks in the tree I used for this patch, hope that's ok.

Attachment #294092 - Flags: review?(mrbkap)
Attachment #294092 - Flags: review?(mrbkap) → review+
Attachment #294092 - Flags: approval1.9+
The overloading of the Date constructor came up as a concern on my blog, as well (Zvents is used by major sites like

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

Closed: 17 years ago
Resolution: --- → FIXED
tests updated in bug 407323 comment 11

Flags: in-testsuite+
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.
Depends on: 432075
No longer depends on: 1409930
No longer depends on: 1409929
You need to log in before you can comment on or make changes to this bug.