307118 - scripts: multiple global objects break isPrototypeOf() and ECMA-262 compliance

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Julien Plissonneau Duquène]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050825 Firefox/1.0.4 (Debian package 1.0.4-2sarge3)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050825 Firefox/1.0.4 (Debian package 1.0.4-2sarge3)

It seems that the current paradigm in JS implementations (Mozilla, Microsoft,
KDE) is to consider that multiple global objects (window) are allowed (see
https://bugzilla.mozilla.org/show_bug.cgi?id=254067#c1 ).

The ECMA-262 specification explicitly states (page 38, 10.1.5) that there is a
unique global object, so I believe that the current behaviour is wrong.

For example, when testing an object created in a parent window:
 - typeof window.opener._some_obj => "object"
 - Object.prototype.isPrototypeOf(window.opener._some_obj) => false
   (expected result => true)

Unfortunately all the browsers I tested exhibited a similar behaviour [IE6 is
even more wrong, since typeof window.opener._some_func will become "object" in a
child window].

It is usually possible to work around this, but since there is no direct way to
know which global object is the global object of a given object, it makes it
harder to test for native object types (such as Date or Array).

A possible fix would be to modify isPrototypeOf() and instanceof to behave as
expected when testing against native ECMAScript objects. There is probably not
too much existing code that depend on the current broken behaviour.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Julien Plissonneau Duquène]

Attachment: tests Object.isPrototypeOf(window.opener._some_obj)

Click on "New window" then "test". The alert box displays the result of typeof
and Object.isPrototypeOf() in different tests.

Actual results : true, false, true, false, false, true
Expected results : true everywhere

Comment 2

[Boris Zbarsky [:bzbarsky]]

As far as I can see, any ECMAScript program we execute has a unique global object (whatever the global JS object is for that scope).  There are some Window objects floating around, but they're not global objects for purposes of that program.

If I understand correctly, ECMA does not define a way to reference the global object short of invoking one of its method (eg calling parseInt or eval).  The fact that there is an explicit "window" object that has such methods doesn't make the "window" the global object (and in point of fact it is NOT in Gecko at the moment).  Similarly, window.opener is not a global object....

All that said, it is possible for an ECMAScript program to get its hands on objects that are hooked up to a different global... the problem there is that sharing globals across trust domains is unacceptable from a security perspective, of course.

As for the suggestion regarding isPrototypeOf(), I'm not sure what we can do in DOM code to affect pure JS operations on JS native objects.  If those are all we're talking about, this should probably be in JS engine.

Comment 3

[Brendan Eich [:brendan]]

ECMA-262 does not require only one global object in all embeddings.  It includes the [[Scope]] property of function objects precisely to allow multiple globals.  In no way does it make all the web browsers on the planet non-conforming or just plain "wrong".

In SpiderMonkey (the JS engine used with Gecko), you can alway use o.__parent__ to reach the global object (which has a null __parent__).  In Edition 4 of the ECMA-262 standard, aka JS2 and possibly JS1.9, there will be universal operators for testing class/instance relationship (is, as operators).

This bug is invalid as reported.  Any IE bugs beyond what all browsers do are bugs to report to Microsoft.

/be

Comment 4

[Julien Plissonneau Duquène]

(In reply to comment #3)
> ECMA-262 does not require only one global object in all embeddings.

Quote ECMA-262-3, 10.1.5: "There is a unique global object, which is created before control enters any execution context". Of course implementations may choose to do things differently under the hood, but if they claim compliance to that spec, they should behave as if there were a single global object.

> It includes the [[Scope]] property of function objects precisely to allow
> multiple globals.

As far as I understand, the [[Scope]] property has more to do with closures and namespaces than object relationships.

> In no way does it make all the web browsers on the planet non-conforming or
> just plain "wrong".

There are certainly very good reasons for the current situation, but the current behaviour where e.g. some objects do not have the current script global Object.prototype for prototype is objectionable.

Actually, as a workaround, adding "if (window.opener) Object = window.opener.Object;" as the first line of the init() function of the test above gave the expected results, and did not break other things yet.

I reopened the bug. I would rather see it closed with "WONTFIX" than "INVALID".

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #4)
> (In reply to comment #3)
> > ECMA-262 does not require only one global object in all embeddings.
> 
> Quote ECMA-262-3, 10.1.5: "There is a unique global object, which is created
> before control enters any execution context". Of course implementations may
> choose to do things differently under the hood, but if they claim compliance to
> that spec, they should behave as if there were a single global object.

Sorry, no.  I created all of JavaScript and the "DOM level 0" (a name invented later) in 1995 for Netscape 2, and I always had multiple global objects.  ECMA chose to simplify for its own purposes, but that is not a normative constraint on the DOM, which predates ECMA.  Your claim is invalid.

> > It includes the [[Scope]] property of function objects precisely to allow
> > multiple globals.
> 
> As far as I understand, the [[Scope]] property has more to do with closures and
> namespaces than object relationships.

Be specific, and don't use terms (namespaces) not relevant to the spec.  It's true that [[Scope]] is also important for closures, but it is required for static scope of functions whose declarations are processed in independent global objects (that is, windows).

> There are certainly very good reasons for the current situation, but the
> current behaviour where e.g. some objects do not have the current script global
> Object.prototype for prototype is objectionable.

On the contrary, it would be objectionable if in a document loaded in a popup,

  var obj = new window.opener.Object;
  alert(obj instanceof Object);
  Object.prototype.foo = "bar";
  alert(obj.foo);

alerted true and "bar" instead of false and undefined.  Two distinct constructor objects (Object and window.opener.Object, which are != and !==) should not have the same prototype object, and cannot across distinct security domains.

Even in a single trust domain, the two are separate, and joining their prototypes into one object just makes a pigeon-hole problem where names collide and the last writer wins.  This is contrary to the entire multiple-window model I created for the DOM.

> Actually, as a workaround, adding "if (window.opener) Object =
> window.opener.Object;" as the first line of the init() function of the test
> above gave the expected results, and did not break other things yet.

Not yet, but it's broken in general.  See above.

Why are you so hung up on there being only one global object?  That makes no sense in a multi-window application where no window is "primary".

> I reopened the bug. I would rather see it closed with "WONTFIX" than "INVALID".

Sorry, it's INVALID.

/be

Comment 6

[Julien Plissonneau Duquène]

(In reply to comment #5)
> ECMA chose to simplify for its own purposes, but that is not a normative
> constraint on the DOM, which predates ECMA.  Your claim is invalid.

My claim is about the current behaviour not being ECMA-262-3 compliant, and as a fact it is not.

> Why are you so hung up on there being only one global object?  That makes no
> sense in a multi-window application where no window is "primary".

It makes sense in a multi-window JS application where one window is designated "primary", shares objects with "child" windows it creates, and tries to dynamically figure out the type of properties of exchanged objects with instanceof / isPrototypeOf.

> Sorry, it's INVALID.

Which means that non-compliance to a spec, despite advertisements of compliance, is not considered a bug.

Comment 7

[Brendan Eich [:brendan]]

(In reply to comment #6)
> (In reply to comment #5)
> > ECMA chose to simplify for its own purposes, but that is not a normative
> > constraint on the DOM, which predates ECMA.  Your claim is invalid.
> 
> My claim is about the current behaviour not being ECMA-262-3 compliant, and as
> a fact it is not.

ECMA-262 any edition is incomplete with respect to real-world DOM level 0.  The real world trumps the paper spec.  This bug is INVALID, not WONTFIX, and to the extent that ECMA-262 is misread as requiring a single global object, it too is invalid.

I'm on ECMA TG1; I'll see about amending the relevant wording for Edition 4.

> It makes sense in a multi-window JS application where one window is designated
> "primary", shares objects with "child" windows it creates, and tries to
> dynamically figure out the type of properties of exchanged objects with
> instanceof / isPrototypeOf.

That case is broken as designed, and has been for over ten years.  Appealing to ECMA-262 doesn't help, because compatibility with the real world trumps a spec that was intentionally divorced from the real-world origins of JS.

> Which means that non-compliance to a spec, despite advertisements of
> compliance, is not considered a bug.

I advise you to wise up.

The real-world web, gmail, Yahoo! oddpost webmail, MSN, flickr, etc. etc. all require the de-facto standard of the DOM level 0 to be implemented by browsers.  This "level" of the DOM was never standardized by the w3c participants who, at the time, were fielding competing browsers, and shame on them.

But all the failures of all the standards processes in the world should not be papered over by the myth that specs trump de-facto standards.  If you disagree, you're on the wrong planet.  Here, filing bugs based on minor flaws in partial specs will not cause us to break the real-world, de-facto standards on which the actual web depends.

/be

Comment 8

[Brendan Eich [:brendan]]

(In reply to comment #7)
> > It makes sense in a multi-window JS application where one window is designated
> > "primary", shares objects with "child" windows it creates, and tries to
> > dynamically figure out the type of properties of exchanged objects with
> > instanceof / isPrototypeOf.
> 
> That case is broken as designed, and has been for over ten years.

I meant to write "broken by design".

I considered such a case 10.5 years ago when hacking JS (Mocha at the time) for Netscape 2, but discarded it as too complex to get right in the time alloted, hard to generalize so that windows once secondary could become primary, and fork their standard objects and global, etc.  The reverse case, a primary window that joins a window-group by being named via window.open, also arises.

I still say it's a hard case that is better addressed within the simplified design (simplistic, if you insist, but it's inarguably simpler for every window to have its own global, than to invent algorithms for sharing globals sometimes, but not others).  But what I say is irrelevant.  The de-facto standard still wins.

Now, I have to apologize for writing harsh words in this bug.  I understand the simplicity you seek, a universally quantified "is" or "instanceof" operator.  That is coming in ECMA-262 Edition 4.

And if we have time, we may even elaborate a way for DOM level 0 compatible scripts to declare that some windows are secondary.  However, we will have to phrase it in a generic way, rather than by specifying a DOM level 0 extension, where "we" == ECMA TG1.  The w3c DOM working group was disbanded, and the only hope for level 0 de-jure specification is with http://www.whatwg.org/.

/be

Comment 9

[Brendan Eich [:brendan]]

One more thing: I walked through dusty hallways and corners of my "Memory Palace" to find a recollection from ECMA-262 Edition 1 days, that we left out multiple globals (and the [[Scope]] property of function objects -- which we should not have left out, it was needed all along, but added only in Edition 3) in order to simplify the spec.  I argued that we should allow for multiple globals, each subjectively "unique", but some reachable from others -- as in the DOM level 0 with window objects.

IIRC, the MS people said that all DOM issues, including window object issues, were "host object" (i.e. embedding-specific) issues, and not to be included in the core spec.  That seemed like good divide-and-conquer, or spec modularity, but we failed to ensure that the core spec worked in a multiple-globals embedding.  As noted above, [[Scope]] was left out.  And as Julien pointed out in email to me, "unique" is the wrong word, even if one added explicit spec-language about subjectivity and how it might affect instanceof or isPrototypeOf.

Striking "unique" and adding an informative annex to Edition 4 are the least we can do to make up for this.  I'll see what else other TG1 members might want to add to Edition 4 to clarify things.

/be