Closed
Bug 598232
Opened 14 years ago
Closed 13 years ago
Nesting evals 8+ times breaks scoping
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
People
(Reporter: appleton, Assigned: brendan)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
text/html
|
Details |
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.
Reporter | ||
Comment 1•14 years ago
|
||
This is also broken in FF4 (4.0b6).
Comment 2•14 years ago
|
||
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.
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 3•14 years ago
|
||
Comment 4•14 years ago
|
||
Attachment #481146 -
Attachment is obsolete: true
Comment 5•14 years ago
|
||
For what it's worth, I expect the bug also doesn't happen in Firefox 3.0 or 3.5...
Comment 6•14 years ago
|
||
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
Comment 7•14 years ago
|
||
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: --- → ?
blocking1.9.2: ? → .12+
status1.9.2:
--- → wanted
Ben: Are you able to work around this? Does it impact the current version or a version in development?
Reporter | ||
Comment 9•14 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.
Updated•14 years ago
|
blocking2.0: ? → beta8+
Updated•14 years ago
|
Assignee: general → brendan
Comment 10•14 years ago
|
||
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
blocking1.9.1: --- → ?
OS: Windows XP → All
Hardware: x86 → All
blocking1.9.1: ? → .16+
status1.9.1:
--- → wanted
Updated•14 years ago
|
blocking1.9.1: .16+ → ---
blocking1.9.2: .13+ → ---
Updated•14 years ago
|
Assignee | ||
Comment 11•13 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.
/be
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•