Re-sent with correct address.
On Fri, Jul 10, 2009 at 5:55 PM, Adam Barth<aba...@eecs.berkeley.edu> wrote: > Eric and I spent some more time this afternoon looking at this. We > don't think the ExecState::thisValue() approach is going to work. We > implemented hacky version to experiment with, but the problem is with > cases like this: > > document.body > > In evaluating this case, the "this" value isn't what we want because > our computed "thisValue" is for the running function, not for the > getter. > > Our current thinking is to add a parameter to toJS() to receive the > JSGlobalObject in which to create the wrapper. Once we do that, the > question is how to find the proper JSGlobalObject at each call site. > > In most cases, you have another JSObject sitting around that is from > the right JSGlobalObject. In the document.body example, the getter > for body has the JSDocument from which it gets the body property. We > can then use Heap::heap(sittingAroundObject)->globalData() to get back > to the right JSGlobalObject. > > Of course, this requires that objects get allocated in the right heap, > which isn't quite the case at the moment because the new operator > takes an ExecState and chooses the heap based on the > lexicalGlobalObject. > > An alternative is to add state to every JSDOMObject to remember with > which JSGlobalObject it's associated. This might have memory > overhead. > > Thoughts? > > Adam > > > On Fri, Jul 10, 2009 at 3:59 PM, Eric Seidel<e...@webkit.org> wrote: >> Geoff, Gavin, Sam, Maciej (and any other JSC experts): >> >> Adam and I are fixing: >> https://bugs.webkit.org/show_bug.cgi?id=27088 >> >> Fix: toJS needs to use the correct global object. The correct global >> object should come from whatever "this" is calling into the native >> code which is using toJS. >> (e.g. document.body. It doesn't matter how/when you access it, the >> correct prototype comes from whichever global object which the >> document was created from.) >> >> >> BACKGROUND EXAMPLE: >> >> <script>frames[0].document.createElement("foo")</script> >> >> Should use "thisValue" as passed into: >> JSValue JSC_HOST_CALL >> jsDocumentPrototypeFunctionCreateElement(ExecState* exec, JSObject*, >> JSValue thisValue, const ArgList& args) >> >> We believe the easiest way to get the correct globalData is via: >> *Heap::heap(thisValue)->globalData() >> >> >> >> QUESTIONS: >> >> We do not need to change the signature of all toJS implementations if >> the ExecState can carry the thisValue for us. >> >> ExecState::thisValue() already exists, but ExecState::codeBlock() >> seems NULL in our case. (thisValue() seems used by the debugger). >> >> >> 1. Is it correct for the ExecState to carry the "thisValue"? >> >> 2. If ExecState is OK to carry "thisValue" how should we fix it to be >> non-NULL in jsDocumentPrototypeFunctionCreateElement (and other >> places)? >> >> >> Thanks, >> Eric & Adam >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
