Summary: | Use sendWithAsyncReply for DecideDestinationWithSuggestedFilename | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alex Christensen <achristensen> | ||||||||
Component: | New Bugs | Assignee: | Alex Christensen <achristensen> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | cdumez, katherine_cheney, thorton, webkit-bug-importer | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | WebKit Nightly Build | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Alex Christensen
2020-03-17 14:38:55 PDT
Created attachment 393791 [details]
Patch
Created attachment 393792 [details]
Patch
Comment on attachment 393792 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=393792&action=review > Source/WebKit/NetworkProcess/NetworkProcess.cpp:2080 > + DownloadID downloadID = networkDataTask->pendingDownloadID(); could be auto downloadID? it's a bit shorter. > Source/WebKit/NetworkProcess/NetworkProcess.cpp:2089 > + networkDataTask->setPendingDownloadLocation(destination, WTFMove(sandboxExtensionHandle), allowOverwrite == AllowOverwrite::Yes); I see the ordering of these statements changed from DownloadManager::continueDecidePendingDownloadDestination(), so now networkDataTask->setPendingDownloadLocation() won't be called if the state is canceling or completed. Was that intentional? That was unintentional, and it was the cause of the test failures. Created attachment 410545 [details]
Patch
Comment on attachment 410545 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=410545&action=review > Source/WebKit/NetworkProcess/Downloads/DownloadID.h:37 > +// FIXME: This should be an ObjectIdentifier. Note: this is being done in https://bugs.webkit.org/show_bug.cgi?id=203962 |