Closed Bug 1053645 Opened 5 years ago Closed 4 years ago

Downloads blocked by Application Reputation are retried on a restart


(Toolkit :: Downloads API, defect)

Windows 8.1
Not set





(Reporter: gcp, Unassigned)


(Blocks 1 open bug)



(1 file)

After trying the STR in Bug 1048508, I noticed that when you restart the browser, we retry the download automatically, i.e. if we block a download because we think it's malware, we will just try to download it again on every next restart.
That means something is going wrong in both the cleanup and retry code, or else the download state is not getting set correctly to DOWNLOAD_DIRTY.

1839 nsDownloadManager::RetryDownload(nsDownload* dl)
1840 {
1841   // if our download is not canceled or failed, we should fail
1842   if (dl->mDownloadState != nsIDownloadManager::DOWNLOAD_FAILED &&
1843       dl->mDownloadState != nsIDownloadManager::DOWNLOAD_BLOCKED_PARENTAL &&
1844       dl->mDownloadState != nsIDownloadManager::DOWNLOAD_BLOCKED_POLICY &&
1845       dl->mDownloadState != nsIDownloadManager::DOWNLOAD_DIRTY &&
1846       dl->mDownloadState != nsIDownloadManager::DOWNLOAD_CANCELED)
1847     return NS_ERROR_FAILURE;

2067 nsDownloadManager::CleanUp(mozIStorageConnection* aDBConn)
2068 {
2069   DownloadState states[] = { nsIDownloadManager::DOWNLOAD_FINISHED,
2070                              nsIDownloadManager::DOWNLOAD_FAILED,
2071                              nsIDownloadManager::DOWNLOAD_CANCELED,
2072                              nsIDownloadManager::DOWNLOAD_BLOCKED_PARENTAL,
2073                              nsIDownloadManager::DOWNLOAD_BLOCKED_POLICY,
2074                              nsIDownloadManager::DOWNLOAD_DIRTY };
2076   nsCOMPtr<mozIStorageStatement> stmt;
2077   nsresult rv = aDBConn->CreateStatement(NS_LITERAL_CSTRING(
2078     "DELETE FROM moz_downloads "
2079     "WHERE state = ? "
2080       "OR state = ? "
2081       "OR state = ? "
2082       "OR state = ? "
2083       "OR state = ? "
2084       "OR state = ?"), getter_AddRefs(stmt));
Paolo, is toolkit/components/downloads/nsDownloadManager.cpp in use any more, or has it been replaced entirely by the modules in toolkit/components/jsdownloads?
Flags: needinfo?(paolo.mozmail)
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #2)
> Paolo, is toolkit/components/downloads/nsDownloadManager.cpp in use any
> more, or has it been replaced entirely by the modules in
> toolkit/components/jsdownloads?

In Firefox for Desktop, we don't use the code from nsDownloadManager.cpp for download management anymore, we use only some methods for retrieving the download directories.

Do we have a persistent URL for testing Application Reputation blocking?
Flags: needinfo?(paolo.mozmail)
Well, that explains it then! :) We don't really have a persistent URL, maybe gcp knows one. The unittests use synthetic lists or a dummy server. I normally modifying shouldBlock=true (terrible hack).
I don't know of any way to test the download protection or verify that it works wrt updates etc. We should probably ask the engineer who wrote it to fix this, or perhaps ask Google if there's any known URLs guaranteed to be on the local/remote blocklists.
Here are two that are showing up on my end.
Blocked on a Windows 8.1 system:
Blocked on a Windows XP system:
Attached file dm-retry
I'm unable to reproduce with this patch or with comment 6. I'm getting the warning but no retries on restart.
To add more context, I am on the Beta upgrades, so I am currently at Firefox 32.0 Beta 8 and this started approximately Firefox 32.0 Beta 2 on the XP. It may have gone back further than that version, but I may not have had something blocked until then. I am pretty sure it was around the time Firefox started to attempt to report crashes and recover pages when it was legitimately closed, though it may have been just before that time also, but not long.
Reproducible on current Nightly:

1) Go to
2) Go to Download->as zip
3) Download fails
4) Is restarted upon restarting the browser
Depends on: 1068664
This may have been fixed by the new interface to unblock downloads. I tried with the malware link at <> and the issue does not seem to happen. Conversely, we don't persist the download information, so the opposite happens and we forget about the placeholder file, as indicated in bug 1139914. I'm closing this bug, feel free to reopen if the issue still happens to you.
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.