I noticed this while looking at an XSS issue, and finding that the console was getting filled with security errors in the console do: a = {get foo(){console.log("wibble");}} <enter> a.<tab repeatedly> watch as the console fills with output (or at least increases the log count for wibble) I'm not sure exactly what the inspector is doing here, but it needs a side effect free way to enumerate properties, and a way to distinguish those properties that can be subsequently accessed without side effects from those that cannot.
Enumerating properties should be side effect free. The issue is that once you have completed a property which is a getter, trying to enumerate it causes a get, which can cause side effects. While it is possible to solve this for vanilla JavaScript objects by checking to see if the property is a getter and not doing a get, I don't think it is possible to solve this for host objects, since any get can potentially have side effects. ie. calling window.document calls a c++ function which can do whatever it wants and we have no way of knowing that. I don't think the host object issue is really that relevant.
Actually, I am not convinced that not getting is a good idea. It seems plausible that someone would want to drill down into an object treating getters as plain old properties (for instance, in debugging the inspector itself, which makes heavy use of getters/setters).
In reality getters don't usually have bad side-affects. Most cases of getters in the inspector code are just foo() { return this.foo }. There is a bug in the Inspector completion code that I can't find yet, but we are triggering the getting in a case where we should not.
The inspector _could_ use getOwnPropertyDescriptor which is ostensibly side effect free.
We use getOwnPropertyNames in TOT.
getOwnPropertyDescriptor can give you the value of a property without calling any getters, etc
This issue seems fixed in ToT (r63644). The original test case produces no output.