Open Bug 482298 (es5strict) Opened 15 years ago Updated 1 year ago

Implement ES5 strict mode


(Core :: JavaScript Engine, defect)






(Reporter: jimb, Assigned: jimb)


(Depends on 1 open bug)


(Keywords: dev-doc-complete)

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.

Summary: SpiderMonkey doesn't implement ECMAScript 3.1 strict mode → Implement ES5 strict mode
This bug needs an owner ;-).

Assignee: general → jim
Yes indeed.
Been working on bug 464750; I'll be better about timesharing and give this one some attention, too.
Depends on: 514559
Depends on: 514560
Depends on: 514562
Depends on: 514563
Depends on: 514564
Depends on: 514567
Depends on: 514568
Depends on: strictThis
Depends on: 514572
Depends on: 514574
Depends on: 514575
Depends on: 514576
Depends on: 514577
Depends on: 514579
Depends on: 514580
Depends on: 514581
Depends on: 514582
Depends on: 514584
Depends on: 514585
Depends on: 515233
Depends on: 516255
Depends on: 516996
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:

  C++ code -> strict mode JavaScript -> C++ JSNative -> some JSAPI fun

it seems wrong to have that JavaScript frame affect what the C++ JSNative is permitted to do.  One can draw an analogy with a pure JavaScript case: when a strict mode JS function calls a non-strict JS function, the latter's behavior is unaffected.  The same principle should hold if the callee is implemented in C++.

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.
Depends on: 521868
Depends on: 522158
Alias: es5strict
Depends on: 541455
Depends on: 537873
Depends on: 534377
Depends on: 521670
Blocks: 553434
When I enable "use strict" in about:config for Minefield, it will not run the ES5 test suite, downloaded from (also available at

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"...
Depends on: 576644
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.
Lars: do you also set the javascript.options.werror boolean option to true via about:config? If not, then you shouldn't be getting any errors (which turn into exceptions), only warnings in the console.

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
So, Lars, just to confirm: if you turn on javascript.options.strict, and not javascript.options.werror, and the ES5 test suite fails to execute correctly, but runs correctly with javascript.options.strict turned off, then that's a bug; if you could file it and CC me, that would be great.

Turning on javascript.options.strict alone should not affect the *execution* of any code, just the warnings it produces. Turning on werror tells the system to treat those warnings as JS errors, which will certainly change the execution of programs that would otherwise run fine.
(I expanded the set of conditions javascript.options.strict complains about, so that we could have the simple rule that the strict option was pickier than ES5 "use strict"; it's confusing enough having them not be the same thing. But I may have inadvertently changed the behavior aside from warnings; that's something I need to know about and fix.)
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?

Depends on: 580932
Depends on: 587249
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.

Depends on: 559402
Depends on: 585536
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.
On the other hand, I'd need some help to document the last point of this part (the point about something changed in how arguments are bound to the actual named arguments)
Depends on: 603201
No longer depends on: 603201
Depends on: 605515
Depends on: 609832
No longer depends on: 585536
Depends on: 621418
Depends on: 621421
No longer depends on: 537873
Depends on: 537873
Depends on: 622271
Depends on: 629187
Depends on: 630332
Depends on: 630543 (mentioned earlier) has long been updated to comprehensively document strict mode, so I think this is documented.
Our strict mode support is pretty much done, as far as I know.
Closed: 12 years ago
Resolution: --- → FIXED
Still one item: bug 605515.
Resolution: FIXED → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.