Investigate `JSGlobalObject == JSDOMGlobalObject` WebCore assumption in presence of Shadow Realms

• Component: WebCore JavaScript
• Status: NEW ---

[Phillip Mates]

A lot of WebCore code assumes that JSGlobalObject instances are the JSDOMGlobalObject subclass.
For example, when `incumbentDOMWindow` is traversing JSGlobalObjects in the callstack, and it assumes that these ones are JSDOMWindow.

After introducing Shadow Realms, via https://bugs.webkit.org/show_bug.cgi?id=230602, this won't necessarily be true. That is WebCore's assumption that `JSGlobalObject == JSDOMGlobalObject` might no longer be valid.

This ticket a is a reminder that we need to investigate this and properly adapt the code if needed

[Radar WebKit Bug Importer]

<rdar://problem/84363152>

[Phillip Mates]

Yusuke, you raised this initially. Looking at `incumbentDOMWindow`, it doesn't seem to be used in api contexts that the shadow realm has access to. For example, in the derived JSDOMWindow.cpp, `incumbentDOMWindow` is used for `postMessage`, `closeBody`, `focusBody`, etc, which won't be exposed to the shadow realm global object.

Can you think of other areas we need to look out for, or perhaps this assumption isn't an issue?

[Yusuke Suzuki]

(In reply to Phillip Mates from comment #2)
> Yusuke, you raised this initially. Looking at `incumbentDOMWindow`, it
> doesn't seem to be used in api contexts that the shadow realm has access to.
> For example, in the derived JSDOMWindow.cpp, `incumbentDOMWindow` is used
> for `postMessage`, `closeBody`, `focusBody`, etc, which won't be exposed to
> the shadow realm global object.
> 
> Can you think of other areas we need to look out for, or perhaps this
> assumption isn't an issue?

What happens if you pass these functions to ShadowRealm and calling it inside ShadowRealm's user function?

[Joseph Griego]

As mentioned on Slack (https://webkit.slack.com/archives/CTV4FGWF4/p1644353301940789) I think we are pretty comfortable not worrying about this, by the usual design of shadow realms, since when we call into parts of the runtime expecting a JSDOMObject on the stack, we will have the incubating realm's global object installed there because of the existing function wrapping;

I'm gonna leave this open, for now, though; since this does change when we install web APIs into the shadow realm context.