[Download Home] More correctly track paused state

[Download Home] More correctly track paused state

The Download Home frontend shouldn't be directly talking
to the Downloads backend because it's missing information
about the downloads that are stored only on the Java side.
Instead, consult the Java sort-of-backend-but-not-really
shared preferences to know whether or not a download is
actually paused or not.

BUG=678099, 651408

[gone, 2017-01-12 01:21:19]

dfalcantara@chromium.org changed reviewers:
+ qinmin@chromium.org, twellington@chromium.org

[gone, 2017-01-12 01:21:20]

Min for the backend, Theresa for the frontend.

[qinmin, 2017-01-12 17:59:46]

https://codereview.chromium.org/2623373002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
(right):

https://codereview.chromium.org/2623373002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java:384:
return mItem.getDownloadInfo().state() == DownloadState.IN_PROGRESS
if the state is not IN_PROGRESS (e.g. interrupted), it should also be paused?

[gone, 2017-01-12 19:55:36]

https://codereview.chromium.org/2623373002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
(right):

https://codereview.chromium.org/2623373002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java:384:
return mItem.getDownloadInfo().state() == DownloadState.IN_PROGRESS
On 2017/01/12 17:59:46, qinmin wrote:
> if the state is not IN_PROGRESS (e.g. interrupted), it should also be paused?

Added this, then moved it into DownloadUtils after offline discussion.

[gone, 2017-01-12 20:04:05]

The CQ bit was checked by dfalcantara@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-12 20:05:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[qinmin, 2017-01-12 21:41:50]

lgtm

[commit-bot: I haz the power, 2017-01-12 22:03:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-12 22:03:30]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Theresa, 2017-01-12 22:19:55]

lgtm % failed test

[gone, 2017-01-12 22:20:39]

The CQ bit was checked by dfalcantara@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-12 22:21:44]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[gone, 2017-01-12 22:26:18]

The CQ bit was unchecked by dfalcantara@chromium.org

[gone, 2017-01-12 22:26:20]

The CQ bit was checked by dfalcantara@chromium.org

[gone, 2017-01-12 22:26:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
twellington@chromium.org, qinmin@chromium.org
Link to the patchset: https://codereview.chromium.org/2623373002/#ps40001
(title: "Move observer [de]registration")

[commit-bot: I haz the power, 2017-01-12 22:27:05]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-13 01:02:50]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1484259980286460,
"parent_rev": "26ff4b57824280ec42599a7c92fcacadfe5201f3", "commit_rev":
"c805e12955f1f3b6030f604a6ff5fd3f909a458a"}

[commit-bot: I haz the power, 2017-01-13 01:16:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-13 01:16:57]

Prior attempt to commit was detected, but we were not able to check whether the
issue was successfully committed. Please check Git history manually and re-check
CQ or close this issue as needed.

[gone, 2017-01-13 01:19:03]

Description was changed from

==========
[Download Home] More correctly track paused state

The Download Home frontend shouldn't be directly talking
to the Downloads backend because it's missing information
about the downloads that are stored only on the Java side.
Instead, consult the Java sort-of-backend-but-not-really
shared preferences to know whether or not a download is
actually paused or not.

BUG=678099,651408
==========

to

==========
[Download Home] More correctly track paused state

The Download Home frontend shouldn't be directly talking
to the Downloads backend because it's missing information
about the downloads that are stored only on the Java side.
Instead, consult the Java sort-of-backend-but-not-really
shared preferences to know whether or not a download is
actually paused or not.

BUG=678099,651408
==========

[gone, 2017-01-13 01:19:20]

Looks like it committed; manually marking Closed.