[Webkit-unassigned] [Bug 234155] [Shadow Realms] Use WebCore module loaders for shadow realm importValue

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 15 14:26:42 PST 2021


https://bugs.webkit.org/show_bug.cgi?id=234155

--- Comment #12 from Yusuke Suzuki <ysuzuki at apple.com> ---
Comment on attachment 447147
  --> https://bugs.webkit.org/attachment.cgi?id=447147
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=447147&action=review

>>> Source/WebCore/bindings/js/JSShadowRealmGlobalScopeBase.cpp:108
>>> +}
>> 
>> Why is it guaranteed that this incubatingWrapper is alive?
>> I think it is possible that the parent one goes away, while this JSShadowRealmGlobalObject is kept alive.
>> Is it correct?
> 
> I wasn't able to think of a scenario where this would happen, but I could have missed something.
> 
> 
> 
> The JSShadowRealmGlobalObject should always be owned by a JSC::ShadowRealmObject whose globalObject is incubatingWrapper.
> 
> ... More importantly, i think, it ought to be impossible to be in an active frame with the shadow realm global object as the active global object unless:
> 
> - a parent call frame has the incubating realm active (i.e. a call via a wrapped function or `ShadowRealm.prototype.evaluate`)
> - or if we are loading module code (via `ShadowRealm.prototype.importValue`) in which case AIUI the event loop for the incubating global object (where we scheduled the module load) guarantees the corresponding JSGlobalObject wrapper should still be around.
> 
> I may have misunderstood some or all of this, though

But what happens if,

1. Create same domain iframe.
2. Create ShadowRealm thing for this iframe's JSDOMGlobalObject
3. Remove iframe while keep refereing ShadowRealm.
4. Then, run script inside ShadowRealm and that script keeps JSGlobalObject alive by setting it to somewhere
5. Then, miss the reference to ShadowRealmObject.

Then, while the ShadowRealm globalObject is alive, parent JSDOMGlobalObject and ShadowRealmObject are GC-ed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211215/c2924e14/attachment.htm>


More information about the webkit-unassigned mailing list