"use strict"; prepended blindly to scripts in the wild

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Tue Sep 14 15:24:37 PDT 2010

The note in section 14.1 advises: "If an appropriate notification mechanism exists, an implementation should issue a warning if it encounters in a Directive Prologue an ExpressionStatement that is not a Use Strict Directive or which does not have a meaning defined by the implementation."

It sounds like it would also be a good idea for implementations to issue such a warning if an "use string" expression statement appears anywhere at the global level that is outside of the Directive Prologue.

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Dmitry Soshnikov
Sent: Thursday, September 09, 2010 11:57 AM
To: Brendan Eich
Cc: es-discuss at mozilla.org
Subject: Re: "use strict"; prepended blindly to scripts in the wild

On Thu, Sep 9, 2010 at 9:35 PM, Brendan Eich <brendan at mozilla.com<mailto:brendan at mozilla.com>> wrote:
On Sep 9, 2010, at 10:33 AM, Dmitry Soshnikov wrote:

On Thu, Sep 9, 2010 at 6:32 PM, Brendan Eich <brendan at mozilla.com<mailto:brendan at mozilla.com>> wrote:
On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:

> Thus the site's combined file won't be globally strict, however since a lib is tested before a production release (at least I hope so ;), then the lib's code should pass the strictness, and therefore, a "use strict" may be even removed from the lib's file. However, if not to remove, then an empty statement is enough.
That does not disable strict mode.

Actually it does (since a strict mode, and the directive prologue is an initial statement):

"use strict";eval=10 // strict, error


;"use strict";eval = 10; // non-strict, OK

Oh, I see -- that solves the problem of strict mode in the second or later parts of the concatenation.

But the problem that's already come up on the web has strict mode enabled in the first part, which complies with strict mode, but later parts do not -- and there's no way to disable for them.

OK, seems I didn't catch the goal then. I though, that there is some single "js-holy-file", which is a combination of some 3rd-party js-files (libs). And one (the first one) of the libs uses strict mode, and other -- do not (that causes issues in the code of later parts, 'cause the whole file becomes strict). But that exactly I proposed -- to insert into the combined file an /empty statement/ _before_ the first part. Thus, the whole single (combined) file will be non-strict. Even if there are several strict directives later (from every part) -- all of them (including the first one) will be canceled because of this inserted empty statement at the beginning of the file.

But repeat, there may be issues with different semantics of /this/ value in strict and non-strict modes. So, as noted, it's just a quick workaround.

Also it won't help if a user uses dynamically loaded js-files from external sources. So, this issue may really be the issue for users of such external files.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100914/8e4ffaf0/attachment.html>

More information about the es-discuss mailing list