Click on downloading webkit nightly build source tarball makes hang on Minibrowser.
Created attachment 167076 [details] Patch
Comment on attachment 167076 [details] Patch Attachment 167076 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14175068
Comment on attachment 167076 [details] Patch Attachment 167076 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/14177050
On EFL port, DownloadManager have the below issue: In DownloadManager::convertHandleToDownload , The downloadID is inserted after Download::startWithHandle called. But when download failed, the DownloadManager::downloadFinished called by the below callstack, and check the downloadID for removing it, then ASSERT FAIL occured because the downloadID is not yet inserted. WebKit::WebFrame::convertHandleToDownload WebKit2/WebProcess/WebPage/WebFrame.cpp:243 WebKit::DownloadManager::convertHandleToDownload WebKit2/WebProcess/Downloads/DownloadManager.cpp:63 WebKit::Download::startWithHandle WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:161 WebKit::DownloadClient::didReceiveResponse WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:95 WebKit::DownloadClient::downloadFailed WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:57 WebKit::Download::didFail WebKit2/WebProcess/Downloads/Download.cpp:149 WebKit::DownloadManager::downloadFinished WebKit2/WebProcess/Downloads/DownloadManager.cpp:81 I think this situation is platform independent, so I wonder why other ports don't have this assert issue when download failed. Is there anyone give me a hint?
Comment on attachment 167076 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=167076&action=review I think you need to make a test case for this crash. > Source/WebKit2/ChangeLog:3 > + [EFL][Minibrowser] Crashes on download link. I think [WK2] is proper bug prefix.
Comment on attachment 167076 [details] Patch This is incorrect. If startWithHandle fails then the error should be called asynchronously.