-
aestes@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=115223 Reviewed by Darin Adler. Source/WebKit2: When WebKit performs a synchronous load on the Mac, it spins a nested run loop in a mode that only accepts input from the NSURLConnection performing the load. When the load is for a custom protocol in WebKit2, we proxy it to the UI process via CoreIPC messages, but the response messages from the UI process are never processed as long as the run loop is in a non-common mode (and we wouldn't want to process messages that could re-enter WebCore in the middle of loading, anyway). Since these messages never make it back to the NSURLConnection handling the request, the connection eventually times out. Fix this by using a work queue to handle custom protocol messages in the networking process. The work queue can process incoming custom protocol messages while the main thread is blocked. * NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::initializeConnection): Called initializeConnection() on all the NetworkProcess's supplements. * Shared/ChildProcessSupplement.h: Added a base class for NetworkProcessSupplement and WebProcessSupplement which defines initializeConnection and provides an empty default implementation. (WebKit::ChildProcessSupplement::~ChildProcessSupplement): (WebKit::ChildProcessSupplement::initializeConnection): * Shared/Network/CustomProtocols/CustomProtocolManager.h: * Shared/Network/CustomProtocols/mac/CustomProtocolManagerMac.mm: (WebKit::CustomProtocolManager::CustomProtocolManager): Instantiated a work queue for message processing. (WebKit::CustomProtocolManager::initializeConnection): Added the work queue as a message receiver on the CoreIPC connection. (WebKit::CustomProtocolManager::initialize): If we're in the web process and the network process is being used, unregister and destroy the work queue we previously created. It'd be better to not create it in the first place, but we have to register our work queue with the CoreIPC connection before it is established, which is before the UI process has told us whether the network process is in use. * Shared/Network/NetworkProcessSupplement.h: Inherited from ChildProcessSupplement. * WebKit2.xcodeproj/project.pbxproj: Added ChildProcessSupplement.h. * WebProcess/WebProcess.cpp: (WebKit::WebProcess::initializeConnection): Called initializeConnection() on all the WebProcess's supplements. * WebProcess/WebProcessSupplement.h: Inherited from ChildProcessSupplement. Tools: Added an API test. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: Added new files. * TestWebKitAPI/Tests/CustomProtocolsSyncXHRTest.mm: Added. (TestWebKitAPI::TEST): Tested that a synchronous XHR does not time out when it loads a request with a custom protocol. * TestWebKitAPI/Tests/WebKit2/custom-protocol-sync-xhr.html: Added. * TestWebKitAPI/Tests/WebKit2ObjC/CustomProtocolsTest.mm: Moved the NSURLProtocol subclass to TestProtocol.{h, mm} and did some miscellaneous cleanup. * TestWebKitAPI/mac/TestProtocol.h: Copied from Source/WebKit2/WebProcess/WebProcessSupplement.h. * TestWebKitAPI/mac/TestProtocol.mm: Copied from Tools/TestWebKitAPI/Tests/WebKit2ObjC/CustomProtocolsTest.mm. (+[TestProtocol canInitWithRequest:]): (+[TestProtocol canonicalRequestForRequest:]): (+[TestProtocol requestIsCacheEquivalent:toRequest:]): (+[TestProtocol scheme]): (-[TestProtocol startLoading]): (-[TestProtocol stopLoading]): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149194 268f45cc-cd09-0410-ab3c-d52691b4dbfc
756003ad