[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 13:47:39 PST 2021


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

Joseph Griego <jgriego at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jgriego at igalia.com

--- Comment #11 from Joseph Griego <jgriego at igalia.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

-- 
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/d5a2615c/attachment.htm>


More information about the webkit-unassigned mailing list