Repository navigation
Change from 0.10 => 1.2; enumerable of this.escape in vm.runInNewContext was false, now true #864
Description
Activity
I guess this is related to https://code.google.com/p/v8/issues/detail?id=3861. GetOwnPropertyNames() is called here.
Testing with
clonePropertyin the REPL correctly generates anescapewithenumerable: false:> c = require('./cloneProperty') [Function: cloneProperty] > s = {} {} > c(global, "escape", s) undefined > s {} > Object.getOwnPropertyDescriptor(s, "escape") { value: [Function: escape], writable: true, enumerable: false, configurable: true }where
cloneProperty.jsis:function cloneProperty(source, key, target) { if (key === 'Proxy') return; try { var desc = Object.getOwnPropertyDescriptor(source, key); if (desc.value === source) desc.value = target; Object.defineProperty(target, key, desc); } catch (e) { // Catch sealed properties errors } } module.exports = cloneProperty;I suspect that's caused by the named property interceptor for the global object here.
if (!in_sandbox || !in_proxy_global) { args.GetReturnValue().Set(None); }
Not sure what the best way to fix it is. The interceptor needs to retrieve the actual property attributes somehow without causing infinite recursion.
- addedvmIssues and PRs related to the vm subsystem.Issues and PRs related to the vm subsystem.
on Feb 17, 2015 - added a commit that references this issue
on Feb 19, 2015 @boordhuis - Indeed, getting attributes for properties of the global is tricky. I have a PR (#885) for the sandbox side, which was easy.
I tried something like this:
Local<Context> context = PersistentToLocal(isolate, ctx->context_); attr = context->Global()->GetPropertyAttributes(property);But that set off an infinite recursion, as you predicted. Any suggestions?
- added a commit that references this issue
on Feb 25, 2015 Looks like the v8 patch landed.
- added a commit that references this issue
on Jun 3, 2015 This can be closed as it's fixed in next.
- added a commit that references this issue
on Jun 17, 2015 - added 9 commits that reference this issue
on Jul 22, 2015
Here's the behavior from node 0.10:
And in
io.js@1.2.0:Is this an intentional change? Is it documented anywhere? FWIW this is present in
node@0.11 as well