Title: [206988] trunk/Source/WebKit2
- Revision
- 206988
- Author
- [email protected]
- Date
- 2016-10-10 00:45:52 -0700 (Mon, 10 Oct 2016)
Log Message
NetworkSession: downloads started by startDownload() can fail before starting from the API point of view
https://bugs.webkit.org/show_bug.cgi?id=163107
Reviewed by Alex Christensen.
In the network process we use a PendingDownload in this case, but in the UI process we always have a single
download proxy. If an error happens before the pending download is converted inot a real download, the DidFail
messages is received in the download proxy before the DidStart one. This is problematic at least for the GTK+
API, because it's common to connect to the started signal and connect to all other signals from there, but in
this case the started signal is never emitted, and then the failed one is not handled. This is not a problem for
downloads started by convertTaskToDownload, because in that case those loads are not considered a download by
the UI process when those early errors happen, and then the web page handles them.
* NetworkProcess/Downloads/PendingDownload.cpp:
(WebKit::PendingDownload::PendingDownload): Send DidStart message right after the network load starts like the
non network session code does.
* NetworkProcess/NetworkLoad.cpp:
(WebKit::NetworkLoad::convertTaskToDownload): Send DidStart message now that the normal load has been converted
into a download.
* NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::findPendingDownloadLocation): Do not send DidStart message here.
Modified Paths
Diff
Modified: trunk/Source/WebKit2/ChangeLog (206987 => 206988)
--- trunk/Source/WebKit2/ChangeLog 2016-10-10 07:28:48 UTC (rev 206987)
+++ trunk/Source/WebKit2/ChangeLog 2016-10-10 07:45:52 UTC (rev 206988)
@@ -1,5 +1,29 @@
2016-10-10 Carlos Garcia Campos <[email protected]>
+ NetworkSession: downloads started by startDownload() can fail before starting from the API point of view
+ https://bugs.webkit.org/show_bug.cgi?id=163107
+
+ Reviewed by Alex Christensen.
+
+ In the network process we use a PendingDownload in this case, but in the UI process we always have a single
+ download proxy. If an error happens before the pending download is converted inot a real download, the DidFail
+ messages is received in the download proxy before the DidStart one. This is problematic at least for the GTK+
+ API, because it's common to connect to the started signal and connect to all other signals from there, but in
+ this case the started signal is never emitted, and then the failed one is not handled. This is not a problem for
+ downloads started by convertTaskToDownload, because in that case those loads are not considered a download by
+ the UI process when those early errors happen, and then the web page handles them.
+
+ * NetworkProcess/Downloads/PendingDownload.cpp:
+ (WebKit::PendingDownload::PendingDownload): Send DidStart message right after the network load starts like the
+ non network session code does.
+ * NetworkProcess/NetworkLoad.cpp:
+ (WebKit::NetworkLoad::convertTaskToDownload): Send DidStart message now that the normal load has been converted
+ into a download.
+ * NetworkProcess/NetworkProcess.cpp:
+ (WebKit::NetworkProcess::findPendingDownloadLocation): Do not send DidStart message here.
+
+2016-10-10 Carlos Garcia Campos <[email protected]>
+
Network Session: PendingDownload is always nullptr in DownloadManager::dataTaskBecameDownloadTask
https://bugs.webkit.org/show_bug.cgi?id=163006
Modified: trunk/Source/WebKit2/NetworkProcess/Downloads/PendingDownload.cpp (206987 => 206988)
--- trunk/Source/WebKit2/NetworkProcess/Downloads/PendingDownload.cpp 2016-10-10 07:28:48 UTC (rev 206987)
+++ trunk/Source/WebKit2/NetworkProcess/Downloads/PendingDownload.cpp 2016-10-10 07:45:52 UTC (rev 206988)
@@ -44,6 +44,8 @@
m_networkLoad->setPendingDownloadID(downloadID);
m_networkLoad->setPendingDownload(*this);
m_networkLoad->setSuggestedFilename(suggestedName);
+
+ send(Messages::DownloadProxy::DidStart(m_networkLoad->currentRequest(), suggestedName));
}
void PendingDownload::willSendRedirectedRequest(WebCore::ResourceRequest&&, WebCore::ResourceRequest&& redirectRequest, WebCore::ResourceResponse&& redirectResponse)
Modified: trunk/Source/WebKit2/NetworkProcess/NetworkLoad.cpp (206987 => 206988)
--- trunk/Source/WebKit2/NetworkProcess/NetworkLoad.cpp 2016-10-10 07:28:48 UTC (rev 206987)
+++ trunk/Source/WebKit2/NetworkProcess/NetworkLoad.cpp 2016-10-10 07:45:52 UTC (rev 206988)
@@ -24,15 +24,17 @@
*/
#include "config.h"
-
#include "NetworkLoad.h"
#include "AuthenticationManager.h"
+#include "DownloadProxyMessages.h"
#include "NetworkProcess.h"
#include "SessionTracker.h"
+#include "WebCoreArgumentCoders.h"
#include "WebErrors.h"
#include <WebCore/NotImplemented.h>
#include <WebCore/ResourceHandle.h>
+#include <WebCore/ResourceRequest.h>
#include <WebCore/SessionID.h>
#include <WebCore/SharedBuffer.h>
#include <wtf/MainThread.h>
@@ -187,6 +189,7 @@
if (!m_task)
return;
+ NetworkProcess::singleton().downloadManager().downloadProxyConnection()->send(Messages::DownloadProxy::DidStart(updatedRequest, String()), downloadID.downloadID());
m_task->setPendingDownloadID(downloadID);
ASSERT(m_responseCompletionHandler);
Modified: trunk/Source/WebKit2/NetworkProcess/NetworkProcess.cpp (206987 => 206988)
--- trunk/Source/WebKit2/NetworkProcess/NetworkProcess.cpp 2016-10-10 07:28:48 UTC (rev 206987)
+++ trunk/Source/WebKit2/NetworkProcess/NetworkProcess.cpp 2016-10-10 07:45:52 UTC (rev 206988)
@@ -513,7 +513,6 @@
void NetworkProcess::findPendingDownloadLocation(NetworkDataTask& networkDataTask, ResponseCompletionHandler&& completionHandler, const ResourceRequest& updatedRequest, const ResourceResponse& response)
{
uint64_t destinationID = networkDataTask.pendingDownloadID().downloadID();
- downloadProxyConnection()->send(Messages::DownloadProxy::DidStart(updatedRequest, String()), destinationID);
downloadProxyConnection()->send(Messages::DownloadProxy::DidReceiveResponse(response), destinationID);
downloadManager().willDecidePendingDownloadDestination(networkDataTask, WTFMove(completionHandler));
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
