@yang, do you know why this is happening?

That sounds a lot like: https://bugs.chromium.org/p/v8/issues/detail?id=3491

TL;DR: Stack-allocated values from scopes outside the current function scope (in which we evaluate) are invisible. This is working as intended because at that point scope analysis for the current function is already done, and we have no way to guarantee that we can correctly resolve these stack-allocated values at all.

One way to make this work is to have the current function reference the variable. That way the variable is context-allocated and visible.

But this *used *to work. why suddenly it stopped working? Sometimes you
dont always have the ability to modify the code. This isnt really a good
solution.

Please try to fix this - Setting a conditional breakpoint should essentially "bring in" the variable and make it context-allocated.

This is preferable to an option to fix the bug you linked there. I can understand it is not a good idea to make every variable accessible, but with conditional breakpoints, it always seemed to bypasss the rule.

What changed in conditional breakpoints?

@yangguo: lets leave it open since this is formally a valid request. Also, the claim here is that it regressed. Could we double check on that?

Yes, i just checked on my other machine with a slightly older version of
chrome

Version it worked previously: 48.0.2564.114
Version it stopped working for me:  49.0.2623.87

Hope the version # helps

There has indeed been a recent change that fixed an issue with wrong variable resolution where we would resolve to a context variable that's actually shadowed by a stack variable. Since the stack variable is invisible, there is no way to tell whether any context variable is correctly resolved unless it is used by the current function itself. So the rule of thumb is: if a variable is not referenced by the function itself, debug-evaluate from the function will not resolve it. Global variables (properties on the global object and variables on the script context) are exempt from this.

That is a correctness fix, and an especially important one when it comes to ES6 arrow functions. Arrow functions do not allocate its own 'this' value, and it may be stack-allocated. In that case it could shadow the 'this' value of an outer scope.

Alas, I'm just guessing that this is what is going on. A concise test case would be nice.

Also, setting a conditional break point does not magically change how scopes are resolved for already compiled code. Much less ones that are on the stack. If the current function does not reference a variable, consider it being optimized away for the function.

This is not a regression or a bug. The old behavior was incorrect, and while it did not exhibit the wrong behavior often, it will with arrow functions introduced with ES6, which will cause a lot more confusion that this.

Unless we introduce a toggle to disable stack-allocation (which would require restarting V8), so that everything is context-allocated, I don't see how this can be correctly implemented. I'd like to wait for more feedback before going that far. Such a toggle would have a discoverability issue, and completely change performance characteristics.

Interesting, but still doesn't explain how it used to work. Vars outside
the scope of the function were always undefined, but using the conditional
breakpoint worked anyway. I know this, because I used that. Constantly.

Let's just say we are working with 100s of instances of modules which have
IDs, so we can break inside the functions when those IDs match to debug
issues on our server. We can't modify the code on the server just to add a
few if statements here and there (the deployment artifact is a single file).

This will basically add some to time it takes to debug these issues, since
we aren't referencing the ID in every function.

Though one "solution" can be to break when the module is instantiated and
then add the ID to the window. Then further conditional breakpoints will be
hit.

Okay, I'm fine with that. A minor inconvenience but I can't tell you guys
to support a feature that never was supposed to work in the first place, I
reckon.

I can see that it is an inconvenience. I do however have an idea that I want to try. Maybe I can make this work for the case where the outer variable is context allocated and not shadowed by a stack allocated variable.

I the meantime, can you provide a test case so I can verify that I'm fixing what broke for you?

Yes, I can come up with a test case. Do you want a jsbin or just some code
snippet will suffice?

Thanks for looking into this, I understand this was never an intentional
feature but the usage of it speeds up my development and debugging
significantly.

Snippets would suffice.

The idea I mentioned in #11 did not work out. Not being able to access outer context variables that are not already resolved is intentional. There is no way to tell whether they are shadowed by any stack variable.

Closing as WAI.