Strict Mode is described in section 10.1.1 of the ECMAScript draft ("Sunnyvale" version, March 2).
Igor reminded me that we have code generation optimizations to nullify updating const-declared bindings and certain JSPROP_READONLY built-ins (the callee named by the function's identifier as an expression, in the body of a named function expression where there is no shadowing arg, var, or let -- and no eval which might make a deletable, shadowing var).
We already have a strict option to enable warnings (which can be errors if you use the separate werror option). So these emitter optimizations are bugs in that they should use the JSREPORT_STRICT, etc., reporting machinery, never mind ES5.
But implementing ES5 strict mode will shake all this up. I would rather we move our existing strict option to agree with ES5 strict mode, except that it warns still (people may count on this in ways that would be hard to change if we suddenly made our strict option imply the werror option).
Alternative: change werror to be the default, allow it to be cleared or toggled off.
In any case we should hope to align the case analysis for our strict option and ES5's strict mode.
This bug needs an owner ;-).
Been working on bug 464750; I'll be better about timesharing and give this one some attention, too.
I just commented.
Jason Orendorff and I talked briefly on IRC about reconciling ES5 strict mode and the JSAPI's JSOPTION_STRICT.
The most direct approach would be to simply equate these two by having existing JSOPTION_STRICT checks also consult the currently running script: while the context's top active frame, if any, is in ES5 strict mode code, the context behaves as if JSOPTION_STRICT were set. While easy to describe, this doesn't seem useful: many JSAPI operations perform JSOPTION_STRICT tests, and if the call stack looks like:
The approach we arrived is to change only those sites that test JSOPTION_STRICT that are clearly performing an operation on behalf of a specific JSScript to also consult that JSScript's strict mode flag.
When I enable "use strict" in about:config for Minefield, it will not run the ES5 test suite, downloaded from http://es5conform.codeplex.com/ (also available at http://kangax.github.com/es5-testsuite/).
It chokes on 12.2.1-11 "arguments as var identifier in eval code is allowed". Is that a known bug or am I doing something wrong? Should I file it?
(I am using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100511 Minefield/3.7a5pre)
(And yes, I have searched Bugzilla as good as thouroughly as I can, but sometimes bugs are filed with very cryptic names for us non-experts.)
Sorry for any confusion. It should be when I enable strict error logging in about:config, not when I enable "use strict"...
Unfortunately, we have two separate meanings of "strict" in play here: the long-standing Mozilla "strict" option, which I believe is what you're enabling with about:config, and the new "use strict" mode defined in EcmaScript 5. We're expanding the former to keep it a superset of the latter, with the exception that 'with' statements, forbidden in ES5 strict mode, are fine under the Mozilla "strict" option.
There's no reason that the ES5 test suite would necessary conform with Mozilla's "strict" option, so I don't think there's a bug to be filed.
If I do that, the test will run, but I get a gazillion errors in the console. And a blank page as the end result.
Most errors are "Function testcase does not always return a value" which seem harmless. But I also get a few "ES5harness is undefined".
Tried today in Mozilla/5.0 (X11; Linux i686; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre
Not sure we need it now due to greater strictness, but does anyone know of a bug on file asking for warning limits to prevent (unintended, in all likelihood) DoS (self-)attacks?
Lars filed bug 580932 per comment 12.
Will this bug be fixed before the release of Firefox 4?
(In reply to comment #16)
> Will this bug be fixed before the release of Firefox 4?
Count on it.
*** Bug 592274 has been marked as a duplicate of this bug. ***
Even if still a bit incomplete (especially the eval part), there is some doc that has been written :
Maybe that the "dev-doc-needed" keyword may be errased from the white board. I was the main author of the article. Feel free to contact me if there is something wrong or inaccurate or even forgotten.
Our strict mode support is pretty much done, as far as I know.
Still one item: bug 605515.