WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
239332
[JSC] ShadowRealm global object has a mutable prototype
https://bugs.webkit.org/show_bug.cgi?id=239332
Summary
[JSC] ShadowRealm global object has a mutable prototype
Caitlin Potter (:caitp)
Reported
2022-04-14 06:56:20 PDT
[JSC] ShadowRealm global object has a mutable prototype
Attachments
Patch
(13.44 KB, patch)
2022-04-14 06:57 PDT
,
Caitlin Potter (:caitp)
no flags
Details
Formatted Diff
Diff
Patch
(13.01 KB, patch)
2022-04-14 14:44 PDT
,
Caitlin Potter (:caitp)
ews-feeder
: commit-queue-
Details
Formatted Diff
Diff
Patch
(12.65 KB, patch)
2022-04-14 15:20 PDT
,
Caitlin Potter (:caitp)
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Caitlin Potter (:caitp)
Comment 1
2022-04-14 06:57:02 PDT
Created
attachment 457622
[details]
Patch
Caitlin Potter (:caitp)
Comment 2
2022-04-14 07:36:56 PDT
Comment on
attachment 457622
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=457622&action=review
> Source/WebCore/ChangeLog:11 > + In addition, it uses the new JSGlobalObject::m_isOrdinaryObject bit to indicate this feature
this is also pretty hacky, maybe this makes more sense as a StructureFlag. It's not clear if we really need this, when we could just remove the assert in all cases.
> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:3210 > + push(@headerContent, " static constexpr unsigned StructureFlags = (Base::StructureFlags & ~JSC::IsImmutablePrototypeExoticObject)");
alternative plan: remove the ImmutablePrototypeExoticObject bit from JSGlobalObject (or explicitly spell out StructureFlags for JSDOMGlobalObject, without the ImmutablePrototypeExoticObject bit), and add it explicitly in classes which inherit it?
Caitlin Potter (:caitp)
Comment 3
2022-04-14 07:36:58 PDT
Comment on
attachment 457622
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=457622&action=review
> Source/WebCore/ChangeLog:11 > + In addition, it uses the new JSGlobalObject::m_isOrdinaryObject bit to indicate this feature
this is also pretty hacky, maybe this makes more sense as a StructureFlag. It's not clear if we really need this, when we could just remove the assert in all cases.
> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:3210 > + push(@headerContent, " static constexpr unsigned StructureFlags = (Base::StructureFlags & ~JSC::IsImmutablePrototypeExoticObject)");
alternative plan: remove the ImmutablePrototypeExoticObject bit from JSGlobalObject (or explicitly spell out StructureFlags for JSDOMGlobalObject, without the ImmutablePrototypeExoticObject bit), and add it explicitly in classes which inherit it?
Darin Adler
Comment 4
2022-04-14 13:06:40 PDT
Need to include a change to the expected result WebCore/bindings/scripts/test/JS/JSShadowRealmGlobalScope.h in the patch. Can generate it with run-bindings-test --reset-results.
Yusuke Suzuki
Comment 5
2022-04-14 13:27:25 PDT
Comment on
attachment 457622
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=457622&action=review
> Source/JavaScriptCore/runtime/JSObject.cpp:1921 > + // Default realm global objects should have mutable prototypes despite having > + // a Proxy globalThis. > + ASSERT((this->isGlobalObject() && this->globalObject()->isOrdinaryObject()) > + || methodTable(vm)->toThis(this, globalObject, ECMAMode::sloppy()) == this);
How about just checking `this->isGlobalObject() || (methodTable(vm)->toThis(this, globalObject, ECMAMode::sloppy()) == this)`? GlobalObject has isImmutablePrototypeExoticObject bit by default. So, reaching here only when we have an exceptional global object (ShadowRealmGlobalObject). If we have a comment about it, then I think `this->isGlobalObject()` is enough and we do not need to have isOrdinaryObject() and its bool field :)
Caitlin Potter (:caitp)
Comment 6
2022-04-14 13:32:12 PDT
Comment on
attachment 457622
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=457622&action=review
(In reply to Darin Adler from
comment #4
)
> Need to include a change to the expected result > WebCore/bindings/scripts/test/JS/JSShadowRealmGlobalScope.h in the patch. > Can generate it with run-bindings-test --reset-results.
Yep, I've got that done locally -- I'm a bit worried about changing these static class properties in case we want to do anything like accessing this metadata at compile time, so I was thinking a refactoring might be preferable... But if that doesn't matter, then I think the hacky version is fine.
>> Source/JavaScriptCore/runtime/JSObject.cpp:1921 >> + || methodTable(vm)->toThis(this, globalObject, ECMAMode::sloppy()) == this); > > How about just checking `this->isGlobalObject() || (methodTable(vm)->toThis(this, globalObject, ECMAMode::sloppy()) == this)`? > GlobalObject has isImmutablePrototypeExoticObject bit by default. So, reaching here only when we have an exceptional global object (ShadowRealmGlobalObject). > If we have a comment about it, then I think `this->isGlobalObject()` is enough and we do not need to have isOrdinaryObject() and its bool field :)
SGTM
Caitlin Potter (:caitp)
Comment 7
2022-04-14 14:44:07 PDT
Created
attachment 457649
[details]
Patch
Yusuke Suzuki
Comment 8
2022-04-14 15:09:39 PDT
Comment on
attachment 457649
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=457649&action=review
> Source/JavaScriptCore/runtime/JSObject.cpp:1920 > + ASSERT((this->isGlobalObject() && this->globalObject()->isOrdinaryObject())
isOrdinaryObject should be removed.
Caitlin Potter (:caitp)
Comment 9
2022-04-14 15:20:03 PDT
Created
attachment 457650
[details]
Patch
EWS
Comment 10
2022-04-14 16:40:15 PDT
Committed
r292895
(
249665@main
): <
https://commits.webkit.org/249665@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 457650
[details]
.
Radar WebKit Bug Importer
Comment 11
2022-04-14 16:41:16 PDT
<
rdar://problem/91785145
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug