When a normal load is converted to a download, the HTTP authentication happens before the load is converted, and the download startes already authenticated. However, downloads started by DownloadManager::startDownload use the DownloadClient API to do the authentication. We don't implement didReceiveAuthenticationChallenge() in our download client, what makes the load to be cancelled and then fail silently. We should probably add API to handle downloads authentication, but we can also forward the authentication to the web view for downloads havign a web view associated. That would cover most of the cases, like downloading from the context menu.
Created attachment 300099 [details] Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Note that this patch doesn't work because of a bug in libsoup, see https://bugzilla.gnome.org/show_bug.cgi?id=777936. Downloads do not allow using stored credentials by default. This matches safari behavior, but I don't think it's desired, it's quite weird that credentials are asked again when downloading something from the context menu, and even more that the HTTP auth dialog is not filled with the stored credentials.
Comment on attachment 300099 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=300099&action=review > Source/WebKit2/ChangeLog:9 > + the download startes already authenticated. However, downloads started by DownloadManager::startDownload use the startes -> starts > Source/WebKit2/ChangeLog:12 > + handle downloads authentication, but we can also forward the authentication to the web view for downloads havign havign -> having
Committed r211407: <http://trac.webkit.org/changeset/211407>