[webkit-dev] ExecState::thisObject()

Sam Weinig sam.weinig at gmail.com
Mon Jul 13 14:18:00 PDT 2009

On Mon, Jul 13, 2009 at 1:57 PM, Eric Seidel <eric at webkit.org> wrote:

> On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen<ggaren at apple.com> wrote:
> > I'm not sure what you guys have been meaning by the phrase "correct
> heap."
> > Barring workers, all WebCore objects are allocated from the same heap.
> We had wrongly assumed that each window got its own.  OK.  This
> invalidates using heaps as a way to get back to a global object, thank
> you.
> > If you want to pass an argument indicating where something should be
> > allocated, I don't think ExecState is the right place to do it. ExecState
> is
> > a read-only pointer into the calling function's stack. It can answer
> > questions about the calling function's state, but that's it.
> It's important for objects to be allocated with the right prototype
> chain, otherwise we will have bugs, some of them security related. :)
> Example:
> A.html:
> <iframe name="B" href="B.html">
> <script>B.doSomething();</script>
> B.html:
> <iframe name="C" href="C.html>
> <script>function doSomething() { return C.contentDocument.body; }</script>
> C.html:
> <body>
> In this example:
> A is the dynamicGlobalObject
> B is the lexicalGlobalObject
> but C is the "current" global object (the one that the
> JSHTMLBodyElement) should be allocated in and from which the
> JSHTMLBodyElement prototype chain should come from.  All browsers get
> variants of this idiom wrong in different places.
> There are two was I can see to fix this:
> 1.  Pass a "current global object" through to all toJS calls (lots of
> callsites changed)
> 2.  Store a "current global object" off of the ExecState (set by the
> JS engine before leaving into custom native code for property lookup
> or function execution).
> I tried #1 this morning, and now think #2 is the cleaner way to go.
> I'm very interested in your thoughts.

I discussed this a bit with Darin and Geoff, and we came to the conclusion
that the correct fix is to have each JS DOMObject store a JSGlobalObject
pointer and augment the toJS methods to pass a global object instead of an
ExecState (close to you #1).  I would not advocate storing more data on the

The tricky part will be getting cases the edge cases such as events and
callbacks correct.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090713/01371370/attachment.html>

More information about the webkit-dev mailing list