On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen<gga...@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.
-eric
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
