Re: [Chrome DevTools] Feature Idea: View all scope variables inside of console
Yury Semikhatsky
I've been thinking about a feature that would save me some time when working with DevTools. The basic idea is that sometimes I just want to log all (or many) of the variables inside of a function, and it can be a bit of work to copy all of the variable names into the console.log() call when I know that I am just going to delete the line afterwards anyway. I would propose a solution called console.scope() that is similar to console.trace(), but it logs scope variables instead of the call stack.I wrote a post detailing this a little more: http://www.briangrinstead.com/blog/devtools-feature-request-console-scope. Is there any interest in a feature like this?
John J Barton
> This would require storing references to all objects accessible from the
> scope chain and may lead to memory leaks caused by DevTools keeping the
> objects alive. Although I believe the feature can be useful I don't think we
> should blindly store the whole scope chain.
'representation' objects which only reference other representation
objects not the heap. The representation for primitives would be
primitives. Representation of the DOM would be a string like "<input
type='text'>...". So the result object would be large but it would not
point outside of itself; as soon as the console is cleared the large
object would be GC fodder. (This is similar to rendering the object to
text without actually rendering it).
For small programs or large closures each representation could be
larger than the program heap. To reduce the performance impact,
console.scope() could take a "depth" argument, where leaves at depth
are rendered to strings. Thus console.depth(1) would give the same
picture as Brian's blog post but the twistys would all give
"console.scope rendered at depth 1" or some such.
jjb
Pavel Feldman
console.log already generates representation disconnected from the heap, it abbreviates strings with a hard-coded threshold and goes 1 level deep (i.e. does not dive into the composite objects).
We can dump scopes using it, but I wonder whether it generates too much noise (scopes are chained and the dumps can get really large). So you also might want to control the depth of enclosing scopes to dump.
Another concern is that we currently operate scopes in debugger only (i.e. while stopped), so it is not that easy to implement - we would need to get scope info at runtime. Depending of the complexity of these we might decide to hold it off.
I wonder if special-casing console.log(arguments) to dump all its items would cover a percentage of your needs. In either case, please file a bug at crbug.org.
Regards
Pavel
