There are a few odds an ends left, mostly related to database callbacks. The one outstanding issue (after this one) is XMLHttpRequest. It uses some different APIs that I need to investigate.
Created attachment 30731 [details] work-in-progress patch Here is a sketch of the patch. I didn't get a chance to finish it tonight, but hopefully I get it done soon.
This turned out to be trickier than expected. We might need more information from the ExecState to do this right. Investigating.
What information is needed?
(In reply to comment #3) > What information is needed? Consider JSCustomXPathNSResolver::create http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSCustomXPathNSResolver.cpp#L53 It's not clear to me that either lexicalGlobalObject or dynamicGlobalObject is the right thing here. It seems like we probably want something equivalent to V8's CurrentContext (i.e., the frame associated with the method itself), but I haven't investigated this in detail. In general, I don't really understand what this file is doing. For example: http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSCustomXPathNSResolver.cpp#L77 That line of code looks really wrong. If the frame has been navigated since this object was created, this code looks like it's grabbing the ExecState for a random SecurityOrigin and calling this lookupNamespaceURI function. Also, consider JSDatabase::transaction http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSDatabaseCustom.cpp#L104 Which frame should we use for the error callback? Presumably the one associated with the database object itself (e.g., CurrentContent), not lexicalGlobalObject or dynamicGlobalObject. Also, I have the same concern about grabbing the ExecState from the Frame after navigation for these database callbacks: http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSCustomSQLTransactionCallback.cpp#L98
Understood, this sounds like a similar concept I think we need for constructing the correct prototype chains for objects.