521670 - Make strict mode (new in ES5) disable undetected document.all emulation

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect, P3)

Description

[Brendan Eich [:brendan]]

This may sound kooky, mixing DOM and quirks-mode per-document concerns with ES5 strict mode (mostly-lexical, per function or script pragma). The hope is that by pivoting around "use strict" (as Perl did) we can base the Harmony edition(s) of the ECMA-262 standard on ES5 strict, thus avoiding (ES-edition x strict-mode) explosive growth of case combinations.

Even more germane to the core JS engine, could we retire JSRESOLVE_DETECTING? We would not want to suppress it in strict mode, since by itself that change would make all document.all uses appear to be undetected, and so the Gecko DOM code would reify document.all. We could either (a) always set JSRESOLVE_DETECTING in strict code, or (b) add JSRESOLVE_STRICT and have the DOM code check that.

Comments?

/be

Comment 1

[Brendan Eich [:brendan]]

By "retire JSRESOLVE_DETECTING" I mean the bytecode-inspection logic that sets it, of course -- so (a) would do that, while (b) would not. (b) would still have the virtue of fixing this bug, though, and we might get around to (a) latter, assuming it was too incompatible a change for embedders to swallow quickly.

/be

Comment 2

[Mark S. Miller]

Shouldn't this be listed as blocking es5strict, not just es5?

Comment 3

[Jim Blandy :jimb]

I like the idea of using "use strict" as the transition point for other breaking changes, but precisely speaking, this bug is not necessary to fix in order to be ES5 conformant.

Comment 4

[Juriy "kangax" Zaytsev]

Would this change make `document.all` evaluate to `undefined` when in strict + quirks modes, rather than to a collection of elements as it does now? Or is it just merely a change in the underlying code without any observable side effects?

Comment 5

[Mark S. Miller]

> Or is it
> just merely a change in the underlying code without any observable side
> effects?

The change would be visible. The current behavior is bizarre: https://bugzilla.mozilla.org/show_bug.cgi?id=248549

> but precisely speaking, this bug is not necessary to fix in
> order to be ES5 conformant.

Actually, it is necessary to fix in order to be ES5 conformant. If the value of document.all when used is a host object, then the value when tested cannot be undefined. If the value when tested is undefined, then the value must simply be undefined. By ES5, nothing is allowed to act like undefined without being the one and only undefined value.

However, practically, the right thing to do is to leave the current bizarre behavior alone for ES5/non-strict code, to accommodate unmaintained IE4-era legacy code. Since no ES5/strict code will be unmaintained IE4-era legacy code, for strict code the value of document.all should simply be undefined. Presumably, by consistently having !('all' in document).

Comment 6

[Mike Shaver (:shaver emeritus)]

(In reply to comment #5)
> Actually, it is necessary to fix in order to be ES5 conformant. If the value of
> document.all when used is a host object, then the value when tested cannot be
> undefined. If the value when tested is undefined, then the value must simply be
> undefined. By ES5, nothing is allowed to act like undefined without being the
> one and only undefined value.

I disagree with this analysis, though I agree that we should fix this bug as summarized.

As far as I can tell, there is nothing in ES5 that prevents a host object like |document| from having a getter that returns undefined sometimes and another value (such as a host object) at other times.  That the decision is based on looking at the syntactic context of the access -- rather than a DOM data structure, network service, or the phase of the moon -- does not seem in violation of ES5.

You may be confusing our behaviour with that of JavaScriptCore, which has a magic object providing conversion-to-boolean that's counter to ES5 (and ES3, for matter).  Or you might be totally right and I'm missing something in ES5; you are certainly more conversant with the details of the specification than I am. :-)

Comment 7

[Brendan Eich [:brendan]]

(In reply to comment #5)
> > Or is it
> > just merely a change in the underlying code without any observable side
> > effects?
> 
> The change would be visible. The current behavior is bizarre:
> https://bugzilla.mozilla.org/show_bug.cgi?id=248549
> 
> > but precisely speaking, this bug is not necessary to fix in
> > order to be ES5 conformant.
> 
> Actually, it is necessary to fix in order to be ES5 conformant. If the value of
> document.all when used is a host object, then the value when tested cannot be
> undefined.

ES5 says nothing like this. The question is not document.all as host object, but document as host object. From 8.6.2:

"Host objects may implement these internal methods in any manner unless specified otherwise; for example, one possibility is that [[Get]] and [[Put]] for a particular host object indeed fetch and store property values but [[HasProperty]] always generates false. However, if any specified manipulation of a host object's internal properties is not supported by an implementation, that manipulation must throw a TypeError exception when attempted."

This bug is trivial to fix. Taking.

/be

Comment 8

[Mark S. Miller]

I agree with the replies in comments 6 and 7. Yes, JSC is clearly non-conformant. FF's behavior is by the letter of ES5 but violates the spirit of the meaning of ES5 syntax. Code transformations which should be equivalence preserving aren't, because of this one host object behavior which depends on syntactic context. (There aren't any others, right? Please not.)

In any case, whether it's technically a violation or not, I'm overjoyed that this will be fixed for ES5/strict. Thanks!

Comment 9

[Brendan Eich [:brendan]]

With bug 792108 resolved, there's no static code property basis for banning undetected document.all emulation.

/be