Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

strict mode detection is too conservative #909

Closed
GoogleCodeExporter opened this issue Apr 6, 2015 · 6 comments
Closed

strict mode detection is too conservative #909

GoogleCodeExporter opened this issue Apr 6, 2015 · 6 comments
Labels
auto-migrated Milestone-v32 Priority-Medium Type-Enhancement

Comments

@GoogleCodeExporter
Copy link 

from src/net/instaweb/rewriter/js_combine_filter.cc:
    // In strict mode of ES262-5 eval runs in a private variable scope,
    // (see 10.4.2 step 3 and 10.4.2.1), so our transformation is not safe.
    // Strict mode is identified by 'use strict' or "use strict" string literals
    // (escape-free) in some contexts. As a conservative approximation, we just
    // look for the text
    if (resource->contents().find("use strict") != StringPiece::npos) {
      *failure_reason = "Combining strict mode files unsupported";
      return false;
    }

This is too conservative for many cases of popular JS libraries where strict 
mode is either enabled in a function closure surrounding the whole file (as 
opposed to the whole file) or simply mentioned in a comment. Note that it is 
safe to concatenate independent scripts that are not strict at the global 
(file) scope but only in functions. Setting strict mode at the global level is 
possible in the first (non-comment) line of the file.

See for details 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_
function_scope/Strict_mode

Original issue reported on code.google.com by robert.b...@goodpoint.de on 17 Mar 2014 at 3:58
@GoogleCodeExporter
Copy link
Author 

Note that the "occurs in a comment" issue shouldn't come up if 
rewrite_javascript is switched on as well.

The others are, of course, still potential problems.  Are there popular JS 
libraries that actually do this?  Solving this problem will add significant 
code complexity, and is really only worth it if it'll have large returns for a 
large number of independent sites.

Original comment by jmaes...@google.com on 17 Mar 2014 at 5:25

@GoogleCodeExporter
Copy link
Author 

The most popular ones I checked don't use it, as it breaks callback behavior 
from non-strict code, e.g. in http://bugs.jquery.com/ticket/13335 a callback to 
jQuery uses arguments.callee to walk up the stack and cannot escape the jQuery 
closure.

However, there are a few semi-popular ones such as:
underscore.string http://epeli.github.io/underscore.string/
SCEditor http://www.sceditor.com/
Rickshaw http://code.shutterstock.com/rickshaw/

Original comment by robert.b...@goodpoint.de on 18 Mar 2014 at 12:27

@GoogleCodeExporter
Copy link
Author 

re: comment #1: That likely regressed in trunk, actually, now we no longer run 
the minifier as a separate filter.

Anyway, may be the new minifier's lexer is accurate enough for us to get it 
right.

Original comment by morlov...@google.com on 18 Mar 2014 at 2:19

@GoogleCodeExporter
Copy link
Author 

We had another report of a user running into this today, suggesting we should 
bump it's priority a bit.  I'll assign to myself to be dealt with in the 
general rewriter priority queue.

Original comment by jmaes...@google.com on 16 Jun 2014 at 3:41

@GoogleCodeExporter
Copy link
Author 

I think I'll take a look at this, actually.

Original comment by morlov...@google.com on 17 Jun 2014 at 3:15

@GoogleCodeExporter
Copy link
Author 

Fixed in r4063

Original comment by morlov...@google.com on 18 Jun 2014 at 5:55

  • Changed state: Fixed
  • Added labels: Milestone-v32

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
auto-migrated Milestone-v32 Priority-Medium Type-Enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter