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

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[good.midget]

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.

Comment 1

[Igor Bukanov]

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

Comment 2

[good.midget]

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?

Comment 3

[Jason Orendorff [:jorendorff]]

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

Comment 4

[Uri Bernstein]

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.

Comment 5

[Brendan Eich [:brendan]]

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

Comment 6

[Brendan Eich [:brendan]]

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

/be

Comment 7

[Brendan Eich [:brendan]]

Attachment: don't use JSCLASS_FIXED_BINDING

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

/be

Comment 8

[John Resig]

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

Comment 9

[Brendan Eich [:brendan]]

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

Comment 10

[Bob Clary [:bc] (inactive)]

tests updated in bug 407323 comment 11

e4x/Regress/regress-407323.js
js1_5/Regress/regress-407323.js

Comment 11

[Bob Clary [:bc] (inactive)]

verified fixed 1.9.0

Comment 13

[Brian Crowder]

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

Comment 14

[Brian Crowder]

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

Comment 15

[Bob Clary [:bc] (inactive)]

crowder, see bug 412324 comment 12