When a download is reputation blocked, download.error is set to a DownloadError with the property becauseBlockedByReputationCheck = true. If DownloadIntegration.shouldKeepBlockedData() returns true (i.e. a Download has been blocked and the data has been kept on disk) download.hasBlockedData is also set to true. If this download is then unblocked (by calling "download.unblock()") it will enter the succeeded state with "download.succeeded = true". Currently we keep the error property to indicate the download was blocked at some point in the past. Having both the succeeded and the error property set is a strange and unintuitive way to indicate this state - we should figure out something better. Properly representing this state is probably only necessary if we actually provide an indication of the state in the UI. This may or may not happen as part of Bug 1068656.
(In reply to Steven MacLeod [:smacleod] from comment #0) > Properly representing this state is probably only necessary if we actually > provide an indication of the state in the UI. This may or may not happen as > part of Bug 1068656. Bug 1068656 has asked for an icon overlay on the download filetype icon to state that it was at some point blocked, even if it is later unblocked. So having this state will be useful, if only for making the code easier to read.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1) > Bug 1068656 has asked for an icon overlay on the download filetype icon to > state that it was at some point blocked, even if it is later unblocked. So > having this state will be useful, if only for making the code easier to read. On Desktop at least, we don't want to persist succeeded Download objects across sessions, so any state stored there would be lost, thus we might as well store it temporarily in the front-end objects. If we want to persist this state across sessions once the download has been unblocked, we should store it for history downloads as well, that currently use Places annotations for the purpose. This adds a little bit of complexity. This might be different for other platforms like Android where a different choice has been made, and all the historical data is stored in the Downloads store until deleted. Also, the reason for blocking, like "uncommon" rather than "malware", might inform our current and historical UI, for example we might show a warning rather than an error icon. So the information we have to persist might not be just a boolean flag. In fact, given that our unblock confirmation messages are pretty clear, I'm not sure how much value there is in storing this information historically. This icon would effectively mean "this file was blocked by mistake". In other words, despite there are mockups, what to do about this state in the back-end is not so obvious :-) Working on the front-end might help us inform our decision.