Title: [178612] trunk/Source/WebCore
- Revision
- 178612
- Author
- [email protected]
- Date
- 2015-01-16 16:12:50 -0800 (Fri, 16 Jan 2015)
Log Message
Web pages fail to load using public iOS WebKit; ASSERT(!isMainThread()) in
-[WebCoreResourceHandleAsOperationQueueDelegate connection:willSendRequest:redirectResponse:]
https://bugs.webkit.org/show_bug.cgi?id=140470
Patch by Pratik Solanki <[email protected]> on 2015-01-16
Reviewed by Alexey Proskuryakov.
Fixes an issue where a web page would fail to load in iOS WebKit2 built with the public iOS SDK
because NSURLConnection callbacks were always being scheduled on the main thread.
Currently we always schedule NSURLConnection callbacks to occur on the WebThread or the main
thread depending on whether the WebThread was started. In iOS WebKit2, the callbacks were
always being scheduled on the main thread regardless of whether we were using the NetworkProcess
(since the WebThread is only started when using WebKit1). This led to an assertion failure.
Instead we want to schedule callbacks to an NSOperationsQueue queue when using WebKit2 with the
NetworkProcess (i.e. ResourceHandleClient::usesAsyncCallbacks() is true), on the main thread when
using WebKit2 without the NetworkProcess and on the WebThread when using WebKit1.
* platform/network/mac/ResourceHandleMac.mm:
(WebCore::operationQueueForAsyncClients): Remove PLATFORM(IOS)-guards as we want to make use
of this code for iOS WebKit2 with the NetworkProcess.
(WebCore::ResourceHandle::start): Modified to use the existing Mac code path to conditionally
schedule NSURLConnection callbacks to an operation queue when ResourceHandleClient::usesAsyncCallbacks()
is true. Otherwise, schedule the callbacks on the run loop returned by WebThreadNSRunLoop(),
which is either the WebThread or the main thread run loop when using WebKit1 and WebKit2 without
the NetworkProcess, respectively.
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (178611 => 178612)
--- trunk/Source/WebCore/ChangeLog 2015-01-17 00:10:59 UTC (rev 178611)
+++ trunk/Source/WebCore/ChangeLog 2015-01-17 00:12:50 UTC (rev 178612)
@@ -1,3 +1,31 @@
+2015-01-16 Pratik Solanki <[email protected]>
+
+ Web pages fail to load using public iOS WebKit; ASSERT(!isMainThread()) in
+ -[WebCoreResourceHandleAsOperationQueueDelegate connection:willSendRequest:redirectResponse:]
+ https://bugs.webkit.org/show_bug.cgi?id=140470
+
+ Reviewed by Alexey Proskuryakov.
+
+ Fixes an issue where a web page would fail to load in iOS WebKit2 built with the public iOS SDK
+ because NSURLConnection callbacks were always being scheduled on the main thread.
+
+ Currently we always schedule NSURLConnection callbacks to occur on the WebThread or the main
+ thread depending on whether the WebThread was started. In iOS WebKit2, the callbacks were
+ always being scheduled on the main thread regardless of whether we were using the NetworkProcess
+ (since the WebThread is only started when using WebKit1). This led to an assertion failure.
+ Instead we want to schedule callbacks to an NSOperationsQueue queue when using WebKit2 with the
+ NetworkProcess (i.e. ResourceHandleClient::usesAsyncCallbacks() is true), on the main thread when
+ using WebKit2 without the NetworkProcess and on the WebThread when using WebKit1.
+
+ * platform/network/mac/ResourceHandleMac.mm:
+ (WebCore::operationQueueForAsyncClients): Remove PLATFORM(IOS)-guards as we want to make use
+ of this code for iOS WebKit2 with the NetworkProcess.
+ (WebCore::ResourceHandle::start): Modified to use the existing Mac code path to conditionally
+ schedule NSURLConnection callbacks to an operation queue when ResourceHandleClient::usesAsyncCallbacks()
+ is true. Otherwise, schedule the callbacks on the run loop returned by WebThreadNSRunLoop(),
+ which is either the WebThread or the main thread run loop when using WebKit1 and WebKit2 without
+ the NetworkProcess, respectively.
+
2015-01-16 Brian J. Burg <[email protected]>
Web Replay: purge remaining PassRefPtr uses and minor cleanup
Modified: trunk/Source/WebCore/platform/network/mac/ResourceHandleMac.mm (178611 => 178612)
--- trunk/Source/WebCore/platform/network/mac/ResourceHandleMac.mm 2015-01-17 00:10:59 UTC (rev 178611)
+++ trunk/Source/WebCore/platform/network/mac/ResourceHandleMac.mm 2015-01-17 00:12:50 UTC (rev 178612)
@@ -105,7 +105,6 @@
request.setHTTPHeaderField(HTTPHeaderName::Authorization, authenticationHeader);
}
-#if !PLATFORM(IOS)
static NSOperationQueue *operationQueueForAsyncClients()
{
static NSOperationQueue *queue;
@@ -116,7 +115,6 @@
}
return queue;
}
-#endif
ResourceHandleInternal::~ResourceHandleInternal()
{
@@ -259,11 +257,6 @@
(NSDictionary *)client()->connectionProperties(this).get());
#endif
-#if PLATFORM(IOS)
- NSURLConnection *urlConnection = connection();
- [urlConnection scheduleInRunLoop:WebThreadNSRunLoop() forMode:NSDefaultRunLoopMode];
- [urlConnection start];
-#else
bool scheduled = false;
if (SchedulePairHashSet* scheduledPairs = d->m_context->scheduledRunLoopPairs()) {
SchedulePairHashSet::iterator end = scheduledPairs->end();
@@ -280,6 +273,12 @@
[connection() setDelegateQueue:operationQueueForAsyncClients()];
scheduled = true;
}
+#if PLATFORM(IOS)
+ else {
+ [connection() scheduleInRunLoop:WebThreadNSRunLoop() forMode:NSDefaultRunLoopMode];
+ scheduled = true;
+ }
+#endif
// Start the connection if we did schedule with at least one runloop.
// We can't start the connection until we have one runloop scheduled.
@@ -287,7 +286,6 @@
[connection() start];
else
d->m_startWhenScheduled = true;
-#endif
LOG(Network, "Handle %p starting connection %p for %@", this, connection(), firstRequest().nsURLRequest(DoNotUpdateHTTPBody));
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
