Our current thinking is to add a parameter to toJS() to receive the JSGlobalObject in which to create the wrapper.
Seems logical.
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.
Heap::heap() will give you a JSGlobalData pointer, but not a JSGlobalObject pointer. All JSGlobalObjects in WebCore share the same Heap and the same JSGlobalData.
Using a different heap for each JSGlobalObject would be a pretty major change.
An alternative is to add state to every JSDOMObject to remember with which JSGlobalObject it's associated. This might have memory overhead.
Almost all DOM access proceeds from [ window ] -> [ document ] -> [ interior stuff ], so it's probably feasible to propagate a window pointer along all chains of property access. This would also be a pretty major change, though.
In JavaScript, it's trivial to figure out the global object that originated execution, and the global object in which the currently executing function was defined. So, if script S calls function F, it's trivial to figure out the window in which S was loaded, and also the window in which F was defined. But figuring out the window from which an arbitrary object originated seems challenging.
Geoff _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
