VM: When applied result of vm.runInContext in 'Object.getOwnPropertyNames(result)' ignores its own property

[princejwesley]

'use strict';
const vm = require('vm');

const name = {
  firstName: 'prince'
};

const ctx = vm.createContext(name);
const result = vm.runInContext('this', ctx);
const ownProperties = Object.getOwnPropertyNames(result);

console.log(ownProperties.indexOf('firstName'));
console.log('result.firstName', result.firstName);
console.log("result.hasOwnProperty('firstName')", result.hasOwnProperty('firstName'));

gives

$ node vmIssue.js
-1
result.firstName prince
result.hasOwnProperty('firstName') true

In the above example, Object.getOwnPropertyNames(result) is not returning its own property.

It affects REPL auto-completion results when useGlobal is false.

[bnoordhuis]

I can confirm the issue. I think it's because firstName lives on the global object's hidden prototype object, not the global object itself. Not sure how to fix that or even if we can or want to fix that.

/cc @domenic

[princejwesley]

Object.keys() in the below code gives expected result.

const ownKeys = Object.keys(result);
console.log(ownKeys.indexOf('firstName'));  // 0

@bnoordhuis Object. getOwnPropertyNames() is a super set of Object.keys(), right?

[domenic]

Which Node version? We recently fixed something related in v3 I think.

The hidden prototype stuff should be unobservable IIRC, and the inconsistency implies something is going wrong here, so yeah, this should be fixable. Even if it's just a V8 issue.

One thing I've been meaning to investigate is using non-masking mode which might help with some of these issues...

[princejwesley]

@domenic I have tested against v4.1.1

[bnoordhuis]

Object. getOwnPropertyNames() is a super set of Object.keys(), right?

Implementation-wise it's nuanced. I did notice that V8's %OwnKeys() intrinsic enumerates named interceptors (that's how the global proxy object is implemented) whereas %GetOwnPropertyNames() doesn't seem to.

(It does have logic around named interceptors using %GetInterceptorInfo() but that returns zero a.k.a. 'no interceptors' . The net result is that ContextifyContext::GlobalPropertyEnumeratorCallback() is never called.)

[princejwesley]

@bnoordhuis Is this same hidden prototype issue?

[bnoordhuis]

@princejwesley No, if I understand you right. Each VM context has its own instance of Object so an object from outside is never an instance of that context's Object.prototype (unless you start mucking about with Object.setPrototypeOf().)

Example:

> const o = {}
> Object.prototype.isPrototypeOf(o)
true

> vm.runInThisContext('Object.prototype.isPrototypeOf(o)')
true

> vm.runInContext('Object.prototype.isPrototypeOf(o)', vm.createContext({o:o}));
false

# and that's because...
> vm.runInContext('this.Object === that.Object', vm.createContext({that:this}))
false

And to be clear, when you call Object.prototype.isPrototypeOf(o), what you're asking is if o has Object.prototype in its prototype chain. It does when it's from the same context, it doesn't when it's from elsewhere.

[princejwesley]

@bnoordhuis thanks, it make sense now.

[jasnell]

@bnoordhuis ... is this actually a bug? this is definitely still happening but it's not clear if it's something that needs fixed.

[bnoordhuis]

It's fixed in master thanks to a recent V8 upgrade. We'll be shipping that as v6.0.0 later this month so I'll go ahead and close the issue.