debugger shows javascript object properties with getters as `undefined`

[weinand]

Objects that have properties with getters / setters incorrectly display the value of the properties as 'undefined'. (See first attached screenshot, 'object3.myprop'). This leads to confusing debugging sessions. In contrast, the Chrome debugger makes it clear that there is a getter which would be invoked. (See second screenshot).

Suprisingly, object properties that have a numeric name will automatically invoke the getter function and display its value (First attached screenshot, 'object4.4').

Note that evaluating the property will yield the value '3' correctly in both cases.

The test code is:

var object3 = {};
Object.defineProperty(object3, "myprop", {
enumerable: true,
configurable: true,
get: function() { return 3; },
set: function(x) { }
});

And for the numeric property:

var object4 = {};
Object.defineProperty(object4, "4", {
enumerable: true,
configurable: true,
get: function() { return 3; },
set: function(x) { }
});

Is it possible to influence how properties with a getter are displayed in the debugger? Or to at least avoid that they are displayed as just 'undefined'.

Thanks in advance!

[felixfbecker]

Indeed annoying for stuff like process.env or XML DOM nodes

[weinand]

The problem is the node debugger protocol. We would fix all those issues if there was an debugger API for that. Node-inspector has exactly the same issues and node-inspector exists much longer than VS Code and has not solved them...

[mjbvz]

If the debugger can evaluate simple expressions, wouldn't Object.getOwnPropertyDescriptor return the required information even if the debugging protocol doesn't natively support inspecting getter/setter properties? Could that be leveraged internally?

[weinand]

@mjbvz sure, that's possible. It is just a bit expensive to probe individual object properties that have a value of undefined via evaluate requests for this information. Until node 0.12.x I was relying on injecting debug protocol extensions into node. But this stopped working in later versions.

[felixfbecker]

@weinand the VS Code debug protocol has this boolean property expensive for variables. Is this suited for this case or what is it being used for?

[weinand]

@felixfbecker a 'Scope' has an optional attribute 'expensive'. It is a hint to the UI to refrain from expanding the scope voluntarily.
It could only help if the debug adapter would know upfront that the variables in this scope would require lots of "evals". But knowing this, would require to walk the tree...

[felixfbecker]

Excuse me, I was mixing things up.

[weinand]

Fix in branch improvedDataTypes or April release.