<br><br><div class="gmail_quote">On Mon, Jul 13, 2009 at 1:57 PM, Eric Seidel <span dir="ltr">&lt;<a href="mailto:eric@webkit.org">eric@webkit.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen&lt;<a href="mailto:ggaren@apple.com">ggaren@apple.com</a>&gt; wrote:<br>
&gt; I&#39;m not sure what you guys have been meaning by the phrase &quot;correct heap.&quot;<br>
&gt; Barring workers, all WebCore objects are allocated from the same heap.<br>
<br>
</div>We had wrongly assumed that each window got its own.  OK.  This<br>
invalidates using heaps as a way to get back to a global object, thank<br>
you.<br>
<div class="im"><br>
&gt; If you want to pass an argument indicating where something should be<br>
&gt; allocated, I don&#39;t think ExecState is the right place to do it. ExecState is<br>
&gt; a read-only pointer into the calling function&#39;s stack. It can answer<br>
&gt; questions about the calling function&#39;s state, but that&#39;s it.<br>
<br>
</div>It&#39;s important for objects to be allocated with the right prototype<br>
chain, otherwise we will have bugs, some of them security related. :)<br>
Example:<br>
<br>
A.html:<br>
&lt;iframe name=&quot;B&quot; href=&quot;B.html&quot;&gt;<br>
&lt;script&gt;B.doSomething();&lt;/script&gt;<br>
<br>
B.html:<br>
&lt;iframe name=&quot;C&quot; href=&quot;C.html&gt;<br>
&lt;script&gt;function doSomething() { return C.contentDocument.body; }&lt;/script&gt;<br>
<br>
C.html:<br>
&lt;body&gt;<br>
<br>
In this example:<br>
A is the dynamicGlobalObject<br>
B is the lexicalGlobalObject<br>
but C is the &quot;current&quot; global object (the one that the<br>
JSHTMLBodyElement) should be allocated in and from which the<br>
JSHTMLBodyElement prototype chain should come from.  All browsers get<br>
variants of this idiom wrong in different places.<br>
<br>
<br>
There are two was I can see to fix this:<br>
1.  Pass a &quot;current global object&quot; through to all toJS calls (lots of<br>
callsites changed)<br>
2.  Store a &quot;current global object&quot; off of the ExecState (set by the<br>
JS engine before leaving into custom native code for property lookup<br>
or function execution).<br>
<br>
I tried #1 this morning, and now think #2 is the cleaner way to go.<br>
I&#39;m very interested in your thoughts.</blockquote><div><br></div><div>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 ExecState. </div>
<div><br></div><div>The tricky part will be getting cases the edge cases such as events and callbacks correct.</div><div><br></div><div>-Sam</div><div><br></div></div>