Repository navigation
vm: Function declarations should use [[Define]] instead of [[Set]] on the global object #31808
Description
Activity
Well,
window.statusdoes get replaced by function declarations in browsers, which is why xhr/status‑async.htm passes in web browsers.This is fixed by 30709
- added a commit that references this issue
on Jun 23, 2020 - added a commit that references this issue
on Jul 15, 2020 - added a commit that references this issue
on Jul 23, 2020 - added a commit that references this issue
on Jul 27, 2020 @Mesteery Does this test pass?
If not, then this issue should remain open.
Surprisingly, this is still an issue. Tested v22.7.0 and v20.17.0. I hope it is OK to cc @targos and @legendecas as people working in the area recently.
Because of this issue jsdom has lots of global properties which are currently data properties, and it is too scary for us to upgrade them to getters + setters (matching specs) because suddenly a bunch of scripts running in the jsdom context might start breaking.
Reacted by Michaël ZassoI don't know if it really is a Node.js bug. V8 calls the
PropertySetterCallback, not thePropertyDefinerCallback(It also happens whenctxis empty).Hmm, OK. Do you know if there's an upstream tracking bug on V8 then? I can try filing one but I think you know more about the relevant code so would be able to file a better one...
Here's a stack trace:
* frame #0: 0x00000001002804f0 node`node::contextify::ContextifyContext::PropertySetterCallback(property=Local<v8::Name> @ 0x000000016fdfbe90, value=Local<v8::Value> @ 0x000000016fdfbe88, args=0x000000016fdfbf88) at node_contextify.cc:549:51 frame #1: 0x0000000100d60c9c node`v8::internal::PropertyCallbackArguments::CallNamedSetter(this=<unavailable>, interceptor=<unavailable>, name=Handle<v8::internal::Name> @ x20, value=Handle<v8::internal::Object> @ x19) at api-arguments-inl.h:227:7 [opt] frame #2: 0x000000010105a580 node`v8::internal::(anonymous namespace)::SetPropertyWithInterceptorInternal(it=0x000000016fdfc148, interceptor=v8::internal::DirectHandle<InterceptorInfo> @ x20, should_throw=(has_value_ = true, value_ = kThrowOnError), value=Handle<v8::internal::Object> @ x19) at js-objects.cc:1306:18 [opt] frame #3: 0x000000010105296c node`v8::internal::JSObject::DefineOwnPropertyIgnoreAttributes(it=0x000000016fdfc148, value=Handle<v8::internal::Object> @ x19, attributes=DONT_DELETE, should_throw=(has_value_ = true, value_ = kThrowOnError), handling=DONT_FORCE_FIELD, semantics=kSet, store_origin=kNamed) at js-objects.cc:3698:18 [opt] frame #4: 0x0000000101051f7c node`v8::internal::JSObject::DefineOwnPropertyIgnoreAttributes(it=<unavailable>, value=Handle<v8::internal::Object> @ x19, attributes=<unavailable>, handling=<unavailable>, semantics=<unavailable>) at js-objects.cc:3643:3 [opt] frame #5: 0x00000001013f5040 node`v8::internal::(anonymous namespace)::DeclareGlobal(isolate=0x0000000128008000, global=<unavailable>, name=Handle<v8::internal::String> @ x21, value=Handle<v8::internal::Object> @ x20, attr=<unavailable>, is_var=<unavailable>, redeclaration_type=kSyntaxError) at runtime-scopes.cc:126:3 [opt] frame #6: 0x00000001013f05d0 node`v8::internal::Runtime_DeclareGlobals(int, unsigned long*, v8::internal::Isolate*) at runtime-scopes.cc:204:3 [opt] frame #7: 0x00000001013f0070 node`v8::internal::Runtime_DeclareGlobals(args_length=<unavailable>, args_object=<unavailable>, isolate=0x0000000128008000) at runtime-scopes.cc:182:1 [opt] frame #8: 0x0000000101f9bcc8 node`Builtins_CEntry_Return1_ArgvInRegister_NoBuiltinExit + 72 frame #9: 0x00000001020c8694 node`Builtins_CallRuntimeHandler + 84 frame #10: 0x0000000101ef37d8 node`Builtins_InterpreterEntryTrampoline + 280 frame #11: 0x0000000101ef0cac node`Builtins_JSEntryTrampoline + 172 frame #12: 0x0000000101ef0950 node`Builtins_JSEntry + 176 frame #13: 0x0000000100a529dc node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [inlined] v8::internal::GeneratedCode<unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, long, unsigned long**>::Call(this=<unavailable>, args=<unavailable>, args=<unavailable>, args=<unavailable>, args=<unavailable>, args=<unavailable>, args=<unavailable>) at simulator.h:187:12 [opt] frame #14: 0x0000000100a529d8 node`v8::internal::(anonymous namespace)::Invoke(isolate=0x0000000128008000, params=0x000000016fdfc608) at execution.cc:420:22 [opt] frame #15: 0x0000000100a53918 node`v8::internal::Execution::CallScript(isolate=0x0000000128008000, script_function=Handle<v8::internal::JSFunction> @ x21, receiver=Handle<v8::internal::Object> @ x20, host_defined_options=Handle<v8::internal::Object> @ 0x000000016fdfc658) at execution.cc:517:10 [opt] frame #16: 0x00000001006f2b24 node`v8::Script::Run(this=0x0000000120829eb0, context=<unavailable>, host_defined_options=<unavailable>) at api.cc:2128:7 [opt] frame #17: 0x0000000100285f14 node`node::contextify::ContextifyScript::EvalMachine(v8::Local<v8::Context>, node::Environment*, long long, bool, bool, bool, v8::MicrotaskQueue*, v8::FunctionCallbackInfo<v8::Value> const&)::$_1::operator()(this=0x000000016fdfc898) const at node_contextify.cc:1252:40We see that
DefineOwnPropertyIgnoreAttributesis called withsemantics=kSet.This seems to be a known limitation:
node/deps/v8/src/objects/objects.h
Lines 108 to 116 in 7fea010
Comment added in v8/v8@4ee68d8
I don't know if there's an open V8 bug about this.
/cc @joyeecheung
Yes I noticed that issue when implementing class fields and avoided that weird behavior with a separate path for class fields. But ordinary Object.defineProperty() still has that old behavior AFAICT. I never got around to investigate whether the old behavior could be broken.
Here is the bug I opened a while back after I discovered that behavior: https://issues.chromium.org/u/2/issues/42202495,
and this is the thread where we discussed how that behavior came to be… https://chromium-review.googlesource.com/c/v8/v8/+/3300092/comments/e98c91dd_75cb8cb2BTW for interceptor-less contexts, there is also #54394 though I am not sure if that meets all the requirements of jsdom (if you care about the constructor of the global object, maybe it doesn't?)
Reacted by snekBased on some initial testing I think
DONT_CONTEXTIFYcan work for jsdom. (We can fix up the constructor by changing the.constructorproperty.)However, since it won't be supported in all active LTS versions until ~May 2026, it isn't very helpful for us now :(
FWIW the next v20.x version will include
DONT_CONTEXTIFYReacted by ExE BossReacted by Domenic Denicola, Joyee Cheung and ExE BossThis issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior?
The functions get defined using
[[DefineOwnProperty]]as specified in ECMA‑262 § 8.1.1.4.18CreateGlobalFunctionBinding.Expected log output
What do you see instead?
Additional information
Discovered in: jsdom/jsdom#2835 (comment)
See also