User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) 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 http://appleton-static.appspot.com/static/ff_nested_eval_bug.html 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.

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:1.9.1.14pre) 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.

For what it's worth, I expect the bug also doesn't happen in Firefox 3.0 or 3.5...

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b14428284d51&tochange=0233d2bb8a07 (sadly 3 days, because the April 7 and 8, 2009 builds crash on this testcase). Regression range for start of crashing: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b14428284d51&tochange=f0507c4d0abb Fix range for crashing: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=96746395df4f&tochange=0233d2bb8a07

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.

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

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.

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.15) Gecko/20101026 Firefox/3.5.15 Why not blocking 1.9.1? I see this bug in Fx 3.5

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. /be