from my understanding 
54.0.2840.85(version) for downloading  chrome is using Download Manger to download,but 61(version) for downloading  chrome is not using DownloadManger.

Tested the issue using Android Intel X86 device and could observe download failed error.

Steps Followed:
1. Launched Browser
2. Navigated to random site
3. Downloaded 10 Mb file
4. Wifi disconnected and connected
5. Observed download failed error

Chrome versions tested:
61.0.3163.98

OS
Android 6.0.1

Android Devices 
5.0.0; ASUS_Z00AD Build/LRX21V

@logesh.sai: Could you please find the above observations and attach a screencast of your issue, that would help us in further triaging of the issue.

Thanks!!

sandeepkumars@, could you provide the actual download URL? There are some cases where we won't retry.

In response to comment #5.

1. Navigated to http://www.engineerhammad.com/2015/04/Download-Test-Files.html
2. Tried downloading 10 MB file
3. Followed the steps in comment #4
4. Observed download failed error

Thanks!!

I attached screencast for Panasonic FZ-A2(panasonic.mp4) and Zebra ET50 (video.mp4). 

Deleted: video.mp4 10.2 MB

	video.mp4 10.2 MB View Download

Deleted: panasonic.mp4 11.1 MB

	panasonic.mp4 11.1 MB View Download

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re-Tested the issue using #61.0.3163.98 on Android 4.4.2; ASUS_T00J Build/KVT49L (Intel X86 device)and could not reproduce the issue.

Steps Followed: 
1. launched Browser
2. Downloaded PDF
3. Disconnected Wifi
4. Reconnected to Wifi
5. Download has resumed.

Unable to check the issue on 6.0.1 on Android Panasonic FZ-A2(panasonic.mp4) and Zebra ET50 as we don't have mentioned devices with us.

Can someone from UI>Browser>Downloads team please take a look at this issue.

Thanks!!

Hmm #7 it doesn't look like the download goes to pending when the network connection goes offline.  qinmin@ can you ptal thanks!

Any Update,which chrome version i can get the fix.

 @sandeepkumars@chromium.org  , please let me know which version i can get the fix.

@sandeepkumars@chromium.org there is no issue in Firefox,resuming of downloading is happening.In chrome I am facing this issue.whether this is correct forum  to report a chrome issues?.

I tested 3 devices with the TOT chromium. The combo was:
 devi     arch         reproducible?
asus      x86           N
coho      x86           Y
nexus    arm64          N

By adding debug log to watch SSL_Read(...) at https://cs.chromium.org/chromium/src/net/socket/ssl_client_socket_impl.cc?q=ssl_client_socket_im&sq=package:chromium&l=1501, I found a potential cause for this bug. If socket read has no errors returned when WIFI goes offline, the bug then happens. See my attached debug logs. Such read errors seem not mandatory according to this post https://stackoverflow.com/questions/12811653/what-happened-to-socket-if-network-has-broken-down.
Probably this is a chance for chromium to improve its connection lose handing of ongoing download.

Deleted: log_asus 151 KB

log_asus 151 KB View Download

Deleted: log_coho 137 KB

log_coho 137 KB View Download

Deleted: log_nexus 69.9 KB

log_nexus 69.9 KB View Download

qinmin@/dtrainor@, could you comment on the above? I think Jie is waiting for some confirmation or directions to go from here before submitting a CL.

The download subsystem waits on error status passed by the the OnResponseCompleted() method to determine whether there is a network disconnection. 

If the socket doesn't return any error, I am curious how the network can determine whether there is a disconnection. Maybe a NETWORK_TIMEOUT error after waiting for too long? Assigning to mmenke@.

Punting back into the triage queue

FWIW, I've managed to reproduce the bug on the Android emulator with an Android Nougat Intel x86 system image and ChromePublic.apk. ChromePublic.apk on my regular, Oreo ARM phone, worked as expected.

Is there anything we can do to help the net team investigate this issue?

Usually a NetLog would be the first thing we look at.
(https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details)

I'm attaching a few different NetLog files. In all cases, I've launched http://speedtest.tele2.net, started downloading the 100MB test file and either activated airplane mode or turned off WiFi.

* net_internal_log-arm-oreo.log is from my own ARM phone running Oreo and the latest Google Chrome Canary. It works as expected, and the socket to tele2.net fails with ECONNABORTED once network access is disabled.
* net_internal_log-x86-nougat.log is from an x86 image running on the emulator with ChromePublic.apk built locally. There's no error when reading the socket, even after network access is disabled, and the download never becomes pending.
* net_internal_log-x86-oreo.log is from another x86 image running on the emulator with ChromePublic.apk. It works just like the ARM Oreo version: the socket fails with ECONNABORTED and the download goes to a pending state.

I also tried an older ARM phone running Marshmallow and the latest Chrome stable: in that case, the socket timed out and the download entered a pending state.

Let me know what else we could provide here.

Deleted: net_internals_log-arm-oreo.json 1001 KB

net_internals_log-arm-oreo.json 1001 KB View Download

Deleted: net_internals_log-x86-nougat.json 708 KB

net_internals_log-x86-nougat.json 708 KB View Download

Deleted: net_internals_log-x86-oreo.json 1.8 MB

net_internals_log-x86-oreo.json 1.8 MB View Download

Without an error on the socket, we don't know if there's still unread data on it, so we don't close HTTP sockets.  Chrome also isn't multi-network aware, so while we see the change, we don't know if it's the network the sockets were using with the change.  We tend to be very conservative on closing sockets (Which works reasonably well for user-controlled sockets, since users can just reload a hung page, but not as well in other contexts).  We do flush idle sockets, clear the DNS cache, and prevent existing H2 streams from being reused on IP chances, though.

Interestingly, H2 has per-platform logic in this case, and it considers Android, Windows, and iOS to be platforms that notify streams of connection errors, and other platforms not to do so (see https://cs.chromium.org/chromium/src/net/spdy/chromium/spdy_session_pool.cc?sq=package:chromium&l=308).

I'm reluctant to just add an entirely arbitrary timeout to the network stack (On Intel Android devices?) specifically for this situation, or to just close all sockets when there's an IP address change.

Thanks; I'll do some digging internally to see if this is some platform bug that got fixed in Oreo.

raphael: I'm marking this Needs-Feedback per your comment #23. Let us know what you figure out.

friendly ping, raphael: is there any update on your end?

I'm still digging, but with no definitive answer from our side yet. I'm working with one of our AOSP engineers to determine if there was something buggy on our end in older releases.

Sorry for the silence. Here's where we stand so far:
* It's very likely that this is caused by a lack of support for SOCK_DESTROY in AOSP Marshmallow (or at least Intel's Marshmallow code base). Namely, the non-exhaustive list of CLs below are present on Nougat and cause the bug to happen there when reverted:
  - https://android-review.googlesource.com/c/kernel/common/+/204348 ("net: diag: Support destroying TCP sockets", whole series in Gerrit)
  - https://android-review.googlesource.com/c/kernel/common/+/364773 ("android: base-cfg: enable CONFIG_INET_DIAG_DESTROY")
  - https://android-review.googlesource.com/c/kernel/common/+/274054 ("net: diag: Add support to filter on device index", whole series)
  - https://android-review.googlesource.com/c/platform/system/netd/+/207783 ("Support killing sockets using SOCK_DESTROY", whole series, this is the userspace side of the changes)
* The network issues with the emulator _can_ be related, but it's not clear and we're not 100% certain.
* It doesn't explain why this has reportedly worked fine on older ARM releases, we're assuming non-AOSP changes are present there.
* It doesn't explain why, according to comment #9, Android IA 4.4.2 was working fine, or why old Chromium releases were working correctly. In both cases I'm assuming the code's undergone a lot of changes and it'd be quite difficult to pinpoint what exactly was responsible for making everything work before.

Given that this is apparently fixed in Nougat, and is (apparently) only an issue on Marshmallow x86, this is probably not worth adding a workaround to Chrome for, given the size of the affected user base.