Closed Bug 521670 Opened 10 years ago Closed 7 years ago
Make strict mode (new in ES5) disable undetected document
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
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
Shouldn't this be listed as blocking es5strict, not just es5?
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.
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?
> 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).
(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
Assignee: general → brendan
Status: NEW → ASSIGNED
blocking2.0: --- → ?
Priority: -- → P3
Target Milestone: --- → mozilla2.0
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!
With bug 792108 resolved, there's no static code property basis for banning undetected document.all emulation. /be
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.