Changeset 51512 in webkit for trunk/JavaScriptCore/runtime

Timestamp:

Nov 30, 2009, 1:48:23 PM (15 years ago)

Author:

[email protected]

Message:

Bug 31859 - Make world selection for JSC IsolatedWorlds automagical.

Reviewed by Geoff Garen.

JavaScriptCore:

WebCore presently has to explicitly specify the world before entering into JSC,
which is a little fragile (particularly since property access via a
getter/setter might invoke execution). Instead derive the current world from
the lexical global object.

Remove the temporary duct tape of willExecute/didExecute virtual hooks on the JSGlobalData::ClientData - these are no longer necessary.

• API/JSBase.cpp:

(JSEvaluateScript):

• API/JSObjectRef.cpp:

(JSObjectCallAsFunction):

• JavaScriptCore.exp:
• runtime/JSGlobalData.cpp:
• runtime/JSGlobalData.h:

WebCore:

WebCore presently has to explicitly specify the world before entering into JSC,
which is a little fragile (particularly since property access via a
getter/setter might invoke execution). Instead derive the current world from
the lexical global object.

Remove the last uses of mainThreadCurrentWorld(), so the world is always obtained via
currentWorld(). Switch this to obtain the world from the ExecsState's lexical global
object instead. Remove the call/construct/evaluate 'InWorld' methods, since these
are no longer necessary.

• WebCore.base.exp:
• bindings/js/JSCallbackData.cpp:

(WebCore::JSCallbackData::invokeCallback):

• bindings/js/JSCallbackData.h:

(WebCore::JSCallbackData::JSCallbackData):

• bindings/js/JSCustomXPathNSResolver.cpp:

(WebCore::JSCustomXPathNSResolver::lookupNamespaceURI):

• bindings/js/JSDOMBinding.cpp:

(WebCore::currentWorld):
(WebCore::mainThreadNormalWorld):

• bindings/js/JSDOMBinding.h:

(WebCore::WebCoreJSClientData::WebCoreJSClientData):

• bindings/js/JSDOMWindowBase.cpp:

(WebCore::JSDOMWindowBase::updateDocument):

• bindings/js/JSDOMWindowBase.h:
• bindings/js/JSEventListener.cpp:

(WebCore::JSEventListener::handleEvent):
(WebCore::JSEventListener::reportError):

• bindings/js/JSHTMLDocumentCustom.cpp:

(WebCore::JSHTMLDocument::open):

• bindings/js/JSNodeFilterCondition.cpp:

(WebCore::JSNodeFilterCondition::acceptNode):

• bindings/js/JSQuarantinedObjectWrapper.cpp:

(WebCore::JSQuarantinedObjectWrapper::construct):
(WebCore::JSQuarantinedObjectWrapper::call):

• bindings/js/ScheduledAction.cpp:

(WebCore::ScheduledAction::executeFunctionInContext):

• bindings/js/ScriptController.cpp:

(WebCore::ScriptController::evaluateInWorld):
(WebCore::ScriptController::initScript):
(WebCore::ScriptController::updateDocument):

• bindings/js/ScriptFunctionCall.cpp:

(WebCore::ScriptFunctionCall::call):
(WebCore::ScriptFunctionCall::construct):

• bindings/js/ScriptObjectQuarantine.cpp:

(WebCore::getQuarantinedScriptObject):

• bindings/js/ScriptState.cpp:

(WebCore::scriptStateFromNode):
(WebCore::scriptStateFromPage):

• bindings/js/ScriptState.h:
• bindings/js/WorkerScriptController.cpp:

(WebCore::WorkerScriptController::evaluate):

• bindings/objc/WebScriptObject.mm:

(-[WebScriptObject callWebScriptMethod:withArguments:]):
(-[WebScriptObject evaluateWebScript:]):

• bridge/NP_jsobject.cpp:

(_NPN_InvokeDefault):
(_NPN_Invoke):
(_NPN_Evaluate):
(_NPN_Construct):

• bridge/jni/jni_jsobject.mm:

(JavaJSObject::call):
(JavaJSObject::eval):

• dom/NodeFilter.h:

(WebCore::NodeFilter::acceptNode):

• dom/NodeIterator.h:

(WebCore::NodeIterator::nextNode):
(WebCore::NodeIterator::previousNode):

• dom/TreeWalker.h:

(WebCore::TreeWalker::parentNode):
(WebCore::TreeWalker::firstChild):
(WebCore::TreeWalker::lastChild):
(WebCore::TreeWalker::previousSibling):
(WebCore::TreeWalker::nextSibling):
(WebCore::TreeWalker::previousNode):
(WebCore::TreeWalker::nextNode):

• inspector/InspectorController.cpp:

(WebCore::InspectorController::windowScriptObjectAvailable):
(WebCore::InspectorController::didEvaluateForTestInFrontend):

• inspector/JavaScriptCallFrame.cpp:

(WebCore::JavaScriptCallFrame::evaluate):

WebKit/mac:

WebCore presently has to explicitly specify the world before entering into JSC,
which is a little fragile (particularly since property access via a
getter/setter might invoke execution). Instead derive the current world from
the lexical global object.

Since WebCore no longer needs to explicitly specify the world on entry to JSC DebuggerCallFrame::evaluate can be called directly.

• WebView/WebScriptDebugDelegate.mm:

(-[WebScriptCallFrame evaluateWebScript:]):

Location:

trunk/JavaScriptCore/runtime

Files:

• JSGlobalData.cpp (modified) (1 diff)
• JSGlobalData.h (modified) (1 diff)

trunk/JavaScriptCore/runtime/JSGlobalData.cpp

@@ -72 +72 @@
 extern JSC_CONST_HASHTABLE HashTable stringTable;
 
-void JSGlobalData::ClientData::willExecute(ExecState*)
-{
-}
-
-void JSGlobalData::ClientData::didExecute(ExecState*)
-{
-}
-
 struct VPtrSet {
     VPtrSet();

trunk/JavaScriptCore/runtime/JSGlobalData.h

@@ -89 +89 @@
         struct ClientData {
             virtual ~ClientData() = 0;
-            virtual void willExecute(ExecState*);
-            virtual void didExecute(ExecState*);
         };