Bug 49409
| Summary: | [v8] Web Inspector: Access to closure variables is limited | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Steven Roussey <sroussey> |
| Component: | Web Inspector (Deprecated) | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Major | CC: | apavlov, bweinstein, joepeck, keishi, loislo, oliver, pfeldman, pmuellr, rik, yurys |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://www.sroussey.com/article/2010/10/25/44165/Debugging-Closures | ||
Steven Roussey
<!DOCTYPE html>
<html>
<head>
<title>Test Case Closures</title>
<script type="text/javascript">
// Similar to firebug test case for issue 2871
function obj()
{
var _this = this;
var www = 'asdasd';
var www2 = 'correct';
this.ttt = 'asd';
this.closure = function()
{
var w = www;
var t = _this.ttt;
rrr = 5;
}
setInterval(this.closure, 2000);
}
function init()
{
var a = new obj();
}
</script>
</head>
<body onload="init()"></body>
</html>
Let us assume that the closure function has an error -- that w is getting the wrong value. Should it be set to www or www2? What are the values of each? Set a breakpoint where "w = www". You can not see the value of www2 via mouseover or watch panel. The example is trivial, but if you the developer of jQuery or similar, it is a common need.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Joseph Pecoraro
I think this is because those variables are optimized out, since they are not used by the closure.
I discussed this a little with Yurys in bug 45260 for Chromium with v8 and I recall hearing that
JSC recently did the same.
Steven Roussey
Only V8 and Spidermonkey have this behavior, and I'm trying to have this fixed in the latter case as well.
I appreciate that an implementation detail causes the bug, and that it might not seem like a bug to the V8 people. But when you go and teach someone about closures, and a student says "what you say about this closure thing can't be true, I just tested it in Chrome and the outer variable really is NOT available -- maybe it is an IE9 bug that variables are leaking into my function -- because, you know, I'm already familiar with C and things just don't work that way," I have to respond, "No, Google is lying to you -- don't trust Chrome's Web Inspector to show you what is *really* going on" all the while knowing full well that it is showing what is real *after* optimizations.
After all, what is the value of test when the debugger breaks on a breakpoint you set on the next line?
function f(){
var test=5;
var s=6;
}
f();
We know full well that that line can be optimized away. With no side effects, the whole function could be optimized away and the breakpoint never get tripped. It's all the same thing.
Oliver Hunt
JSC should not exhibit this problem as JSC recompiles all functions when the debugger is enabled. When the debugger is enabled we don't throw away uncaptured variables.
Timothy Hatcher
Chromium and V8 have left the building. Won't fix.