Nesting evals 8+ times breaks scoping




8 years ago
8 years ago


(Reporter: appleton, Assigned: brendan)


(Blocks: 1 bug)


Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted, status1.9.2 wanted, status1.9.1 wanted)




(1 attachment, 1 obsolete attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100914 Firefox/3.6.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100914 Firefox/3.6.10

I work on the Google Maps API.  Google's JavaScript Maps APIs load obfuscated JavaScript into 3rd-party pages.  It's important that we do not leak many short variable names into the global scope, so we wrap our JavaScript in an anonymous closure.  When we load a JavaScript module, this module must be evaluated in the scope of the main library so that the module can access common utility functions.  Therefore the main library exports a function that will eval a module in a child scope of the main library.

When loading dependent modules, we nest these evals.  For example if module C depends on module B depends on module A, we eval module B in the scope of module A (and B exports an evaluator), then we eval module C in the scope of module B (using B's evaluator).

As the module dependency graph grows, we have discovered that FF3.6 limits the number of nested evals to approximately 8.  After this point, any closures in the deep module lose track of their scope so they cannot resolve references to outer variables.  The URL provided above boils this down to a few lines of JS.

This bug does not affect FF2, nor other browsers (I've checked at least Chrome, Safari, IE7).

Reproducible: Always

Steps to Reproduce:
1. Load
2. Observe result.
Actual Results:  
After 7 evals, the inner function's reference is broken, so that "typeof me" becomes undefined.  See page source for more information.  I've added comments to clarify what the JS is doing.

Expected Results:  
"typeof me" should be "object" for every level of nested eval.

I have FireBug installed.  The error appears with and without FireBug enabled, so I suspect that's not the problem.

I have verified this bug occurs on FF3.6.10 on WinXP and Linux.  This bug does not occur on FF2/Linux.

Comment 1

8 years ago
This is also broken in FF4 (4.0b6).
Confirmed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre

Using Safe Mode to disable JIT does not make a difference.

Also happens in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100925 Shiretoko/3.5.14pre

This may be a duplicate since its been around for that long, but I'm not able to find a matching bug.
Assignee: nobody → general
Component: General → JavaScript Engine
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
blocking2.0: --- → ?
Created attachment 481147 [details]
Testcase for real
Attachment #481146 - Attachment is obsolete: true
For what it's worth, I expect the bug also doesn't happen in Firefox 3.0 or 3.5...
I'm betting this is an upvar2 issue given the regression range for the crashing.

The fix range for the crashing has bug 487271 in it, which I bet might be relevant.
Blocks: 452598
blocking1.9.2: --- → ?


8 years ago
blocking1.9.2: ? → .12+
status1.9.2: --- → wanted

Comment 8

8 years ago
Ben: Are you able to work around this? Does it impact the current version or a version in development?

Comment 9

8 years ago
This impacts a version in development, not a current version - I backed out the change when I discovered the issue.  However we would like to reinstate the change as new modules are bumping into this issue.


8 years ago
blocking2.0: ? → beta8+
Assignee: general → brendan

Comment 10

8 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20101026 Firefox/3.5.15

Why not blocking 1.9.1? I see this bug in Fx 3.5
blocking1.9.1: --- → ?
OS: Windows XP → All
Hardware: x86 → All


8 years ago
blocking1.9.1: ? → .16+
status1.9.1: --- → wanted
blocking1.9.1: .16+ → ---
blocking1.9.2: .13+ → ---


8 years ago
blocking2.0: beta8+ → final+


8 years ago
blocking2.0: final+ → -
status2.0: --- → wanted

Comment 11

8 years ago
This WFM in Firefox 4. I'm going to try being bad cop on not supporting downrev code. We need to upgrade our installed base to Firefox 4 and get them on the fast release trains.

Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.