Display download progress

[eloquence]

We're currently only displaying a spinner for download activity. For a large download, it would be useful to let the user know how much of the file has already been downloaded.

Key questions to address include:

• What implementation strategy do we want to use to update the client's knowledge of download progress?
• What information do we want to display (in a first iteration, in future iterations)? For comparison, Firefox shows:
  • estimated time remaining
  • [kilo/mega]bytes downloaded
  • [kilo/mega]bytes remaining
  • estimated throughput
  • progress bar
• Is that information constrained by the technical choice above?
• If a file is not yet downloading but only queued to be downloaded, what should the progress indicator say?

[ninavizz]

Cross-referencing to Conversation Pane refinement EPIC in SD-UX repo.

[philmcmahon]

Just adding some user feedback on this - any indication of download progress would be very useful as it's not currently clear whether a download is still in progress or has failed:

"We've not yet successfully downloaded any files larger than a megabyte, whereas we frequently receive files of up to 500Mb. All I see is "Downloading" for long periods (involving multiple screenlocks) until giving up after an hour or so."

[cfm]

Last Thursday @tina-ux and I discussed @eloquence's question in https://github.com/freedomofpress/securedrop-client/issues/1104#issue-634802183:

What implementation strategy do we want to use to update the client's knowledge of download progress?

When downloading messages and files we already do—

https://github.com/freedomofpress/securedrop-client/blob/8aa77b89392a68886470eaaf2d4351b2f9b05cdf/securedrop_client/api_jobs/downloads.py#L318-L320

—meaning that we have access to both (a) the actual size of the file we're downloading and (b) an estimate of how long it should take to download.

When fetching metadata takes a long time, it appears that we do get a Content-Length header we could pass to a generalized form of _get_realistic_timeout(size_in_bytes: int):

https://github.com/freedomofpress/securedrop-client/blob/8b2f0d404e869fbeff7afa07aca21a57d9da393f/tests/functional/cassettes/test_login_as_journalist.yaml#L150-L152

In either case, to report on actual progress, we'll need securedrop-proxy to support streaming responses (e.g.).

[rocodes]

get_realistic_timeout is a theoretical ceiling above which we are declaring the download to be failed/stalled, and is not based on the user's current network conditions. Ideally we want a way of reporting true connection speed (and/or comparing true download progress to some benchmark numbers to decide if we're making "good" or "poor" progress), which is maybe what you're suggesting with sd-proxy

[cfm]

Yes, exactly.

[rocodes]

Ok, so the only small issue I see there is we probably want another option (get_non_depressing_realistic_timeout? :sob:) to benchmark against, since I will probably bump up our defintion of "realistic" in order to accommodate wider range of network conditions. But it won't be hard to include that logic.

I haven't looked at the proxy code. Do you have a sense of how readily those changes could be made? Even if we haven't finalized the UX implications for the client (in terms of how we report on the download speed/progress), we could start by making sure the info is accessible in the client.