Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 482298 - (es5strict) Implement ES5 strict mode
: Implement ES5 strict mode
: dev-doc-complete
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Linux
: -- normal with 8 votes (vote)
: ---
Assigned To: Jim Blandy :jimb
: Jason Orendorff [:jorendorff]
: 592274 (view as bug list)
Depends on: 605515 514559 514560 514562 514563 514564 514567 514568 strictThis 514572 514574 514575 514576 514577 514579 514580 514581 514582 514584 514585 515233 516255 516996 521670 521868 522158 534377 537873 541455 559402 576644 580932 587249 609832 621418 621421 622271 629187 630332 630543
Blocks: es5 553434
  Show dependency treegraph
Reported: 2009-03-09 12:27 PDT by Jim Blandy :jimb
Modified: 2016-03-08 14:07 PST (History)
33 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Jim Blandy :jimb 2009-03-09 12:27:59 PDT
Strict Mode is described in section 10.1.1 of the ECMAScript draft ("Sunnyvale" version, March 2).
Comment 1 Brendan Eich [:brendan] 2009-04-13 17:10:21 PDT
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.

Comment 2 Brendan Eich [:brendan] 2009-05-09 13:12:54 PDT
This bug needs an owner ;-).

Comment 3 Jim Blandy :jimb 2009-05-11 10:05:04 PDT
Yes indeed.
Comment 4 Jim Blandy :jimb 2009-07-01 10:51:56 PDT
Been working on bug 464750; I'll be better about timesharing and give this one some attention, too.
Comment 5 Brendan Eich [:brendan] 2009-08-06 11:42:36 PDT

I just commented.

Comment 6 Jim Blandy :jimb 2009-09-17 11:38:24 PDT
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.
Comment 7 Lars Gunther 2010-05-14 05:02:43 PDT
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.)
Comment 8 Lars Gunther 2010-05-15 01:39:15 PDT
Sorry for any confusion. It should be when I enable strict error logging in about:config, not when I enable "use strict"...
Comment 9 Jim Blandy :jimb 2010-07-19 13:12:13 PDT
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.
Comment 10 Brendan Eich [:brendan] 2010-07-19 15:57:15 PDT
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.

Comment 11 Lars Gunther 2010-07-21 01:43:19 PDT
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
Comment 12 Jim Blandy :jimb 2010-07-21 15:17:40 PDT
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.
Comment 13 Jim Blandy :jimb 2010-07-21 15:22:31 PDT
(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.)
Comment 14 Brendan Eich [:brendan] 2010-07-21 17:10:01 PDT
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?

Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2010-07-22 08:23:52 PDT
Lars filed bug 580932 per comment 12.
Comment 16 Scott Sims 2010-08-17 05:36:20 PDT
Will this bug be fixed before the release of Firefox 4?
Comment 17 Brendan Eich [:brendan] 2010-08-17 12:28:35 PDT
(In reply to comment #16)
> Will this bug be fixed before the release of Firefox 4?

Count on it.

Comment 18 Brendan Eich [:brendan] 2010-08-31 10:46:54 PDT
*** Bug 592274 has been marked as a duplicate of this bug. ***
Comment 19 David Bruant 2010-10-10 08:27:28 PDT
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)
Comment 20 Jeff Walden [:Waldo] (remove +bmo to email) 2012-04-28 11:00:00 PDT (mentioned earlier) has long been updated to comprehensively document strict mode, so I think this is documented.
Comment 21 Jim Blandy :jimb 2012-05-08 17:35:45 PDT
Our strict mode support is pretty much done, as far as I know.
Comment 22 Jason Orendorff [:jorendorff] 2016-01-22 12:54:06 PST
Still one item: bug 605515.

Note You need to log in before you can comment on or make changes to this bug.