"Download Pending" state lasts awhile |
|||||
Issue descriptionVersion: Canary 56.0.2919.0 OS: Android When using the background loader, the download pending state lasts a long time from both Async and "download link" action on NTP. What steps will reproduce the problem? (1) Turn on Async (go/try-paquete-async) (2) Go into airplane mode and open a page. (3) Select "Download page later" (4) Reconnect to network (5) Notification switches to pending. (6) Close Chrome/Put device to sleep. (4) Pending state lasts a long time. What steps will reproduce the problem? (1) Open NTP. (2) Scroll down to suggestions (3) Long press on item and select "Download link" (4) Pending state lasts a long time. What is the expected result? - From Async, device should try to download page when user reconnects to network unless there's a high risk of crashing. - From NTP, device should try to download page immediately unless there's a high risk of crashing
,
Nov 15 2016
,
Nov 15 2016
,
Nov 16 2016
Looks like this is do to new check for current network connection and apparent lag in it agreeing there is a network compared to Android Scheduler triggering on new network connection.
,
Nov 16 2016
After talking to Tal today my impression was this is more a P1 for M56 than a P3. Tal, correct? :)
,
Nov 16 2016
,
Nov 17 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ff642e8ff58fefd407c1af7e2f74284c00d65d5f commit ff642e8ff58fefd407c1af7e2f74284c00d65d5f Author: dougarnett <dougarnett@chromium.org> Date: Thu Nov 17 19:46:03 2016 [OfflinePages] Fix Coordinator issue with lagging NetworkChangeNotifier Use current device conditions in TryNextRequest to decide if have network connection currently since NetworkChangeNofifier might not be updated before GcmNetworkManager is and kicks StartProcessing. BUG= 665551 Review-Url: https://codereview.chromium.org/2508213002 Cr-Commit-Position: refs/heads/master@{#432936} [modify] https://crrev.com/ff642e8ff58fefd407c1af7e2f74284c00d65d5f/components/offline_pages/background/request_coordinator.cc [modify] https://crrev.com/ff642e8ff58fefd407c1af7e2f74284c00d65d5f/components/offline_pages/background/request_coordinator.h
,
Nov 21 2016
Hi, since this bug is not marked fixed, I assume you do have your own list of remaining work items here already. But just to confirm, I am still seeing extremely long download times in Canary 56.0.2924.0, which comes from a later revision (#433059) than the last CL on this bug. Patrick
,
Nov 21 2016
Patrick, can you provide a bit more detail on what you're experiencing (device, network you're using, etc.)? I've actually seen the regression behavior resolved on the latest canary.
,
Nov 21 2016
Since M-56 has branched, I would like to mark this one fixed for the regression. Patrick, do you want to open a new one with your details? [From what I saw, there should be no noticeable latency for the first request and switching network back on. But if you switch network off again and make another request, then I did hit latency switching network on after that.] |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by talo@chromium.org
, Nov 15 2016