Investigate better representing a previously blocked Download which had unblock() called.

NEW
Unassigned

Status

()

Firefox
Downloads Panel
3 years ago
2 years ago

People

(Reporter: smacleod, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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.
Flags: firefox-backlog+
(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.

Comment 2

3 years ago
(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.
You need to log in before you can comment on or make changes to this bug.