New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 798131 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Downloads are canceled when laptop goes to sleep (lid closed)

Reported by navin.ku...@gmail.com, Dec 30 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Example URL:
chrome://downloads

Steps to reproduce the problem:
1. Start a download
2. Close laptop lid 

What is the expected behavior?
The download should resume. Ideally, with no user interaction. 

The error message should be changed. It should never say "Canceled" unless the user clicked the cancel button. 

What went wrong?
The download is "Canceled" and the only button available is "RETRY".

Did this work before? N/A 

Chrome version: 63.0.3239.84  Channel: stable
OS Version: OS X 10.13.2
Flash Version: 

I'd love to get some tips on where to start debugging this.
 
Screen Shot 2017-12-30 at 3.39.16 PM.png
184 KB View Download

Comment 1 by meh...@chromium.org, Dec 30 2017

Components: UI>Browser>Downloads
Able to reproduce this issue on reported version 63.0.3239.84 and on latest canary 65.0.3309.0 using Windows 10, Mac 10.13.1, this issue is seen from M50[50.0.2661.0]. Hence considering this issue as Non-Regression and marking as Untriaged.

Observation: This issue is not seen on Ubuntu 17.10

Thanks!
Cc: viswatej...@techmahindra.com sc00335...@techmahindra.com
Labels: M-65 Needs-Triage-M63 Triaged-ET OS-Windows
Status: Untriaged (was: Unconfirmed)
Cc: asanka@chromium.org
Status: Unconfirmed (was: Untriaged)
I believe this is WorkingAsIntended, and as such, may be a feature request rather than a bug. Asanka, can you confirm?
Components: -Internals>Network
Removing the network stack label - sockets all die when a computer goes to sleep, and resuming all network requests seems not practical, though resuming downloads may be a specific case worth handling.
Labels: Needs-Feedback
Yeah, in this case the error code that's bubbling up to downloads may be ambiguous, thus preventing the downloads layer from reliably detecting this particular condition.

A net-internals log that spans a lid closure + open while a download is on-going should be sufficient to figure out the sequence of events observed. https://dev.chromium.org/for-testers/providing-network-details has information on how to collect such a log.

Could either the reporter or someone reproducing this issue attach such a log? It might be worth capturing from different OSs (Mac, Windows, Linux, ChromeOS) to determine what's going on under the hood.
Cc: xingliu@chromium.org
Owner: qin...@chromium.org
Status: Assigned (was: Unconfirmed)
Min can you take a look?  We can grab the report and see if there is anything useful in the logs.  Agreed it's probably a good idea to try capturing logs from multiple OSes here.

+xingliu@ for windows laptop logs

Sign in to add a comment