Closed Bug 437415 Opened 14 years ago Closed 14 years ago

Entering offline mode should pause active downloads


(Toolkit :: Downloads API, defect)

Not set





(Reporter: sdwilsh, Assigned: sdwilsh)


(Blocks 1 open bug)


(Keywords: verified1.9.1)


(2 files, 2 obsolete files)

See bug 436382 comment 17
Flags: in-testsuite?
Flags: wanted1.9.0.x?
Flags: blocking-firefox3.1?
On OSX (10.5.3) what I see is ..:

 - start downloading files
 - File > Work Offline
 - one download completes early (file is corrupted)
 - one download sorta sits there

If I go back online, I can click pause and then resume on the "stuck" download and things work fine.

As mentioned in summary, the expected result should be that in progress downloads are paused, and when we go back online, they resume.

This should be the same for manually going online/offline and automatically detecting when we're online/offline (on Win/Linux where we get that signal from the OS)
Attached patch v0.1 (obsolete) — Splinter Review
work in progress.  Test case crashes right now, but I think it's because I'm toggling offline state inside the listener.
Assignee: nobody → sdwilsh
Attached patch v1.0 (obsolete) — Splinter Review
With a functioning test.  Note, we may have to revisit how we do resumable downloads because there appears to be a timing issue that makes it so the server sends all the file before we can pause, making us get the NS_ERROR_ENTITY_CHANGED result back.  This happened to me when I had a VM in the background compiling mozilla with static checking.
Attachment #324069 - Attachment is obsolete: true
Attachment #324079 - Flags: review?(edilee)
Whiteboard: [has patch][needs review Mardak]
Are we canning the sleep/wake test for now or does it get covered by the offline-online case? If that's the case, do we still need to sleep/wake notification check in nsDownloadManager is the online/offline notifications are the better ones to be checking?
It's not clear to me that the network goes away when we go to sleep/wakeup.  I don't see any code in necko to handle that, but then I'm still not that strong with that part of the codebase.

I think it doesn't hurt us to be overly cautious - I'm fine with removing our tests and code when I see unit tests in necko for shutting down the network when we go to sleep.
Blocks: 438042
I filed bug 438040 for necko, and bug 438042 for the download manager
Attached image Image of bug
An image of what happened after I selected "Work Offline" while downloading two files. Both files failed and after returning to working online status, both files "finished" without downloading the rest of the file and was left corrupted with the part file also.
Attachment #324079 - Flags: review?(edilee) → review?(
Whiteboard: [has patch][needs review Mardak] → [has patch][needs review gavin]
Attachment #324079 - Flags: review?( → review+
Whiteboard: [has patch][needs review gavin] → [has patch][has review][can land]
I'll push my own bugs - thanks!
Keywords: checkin-needed
Attached patch v1.1Splinter Review
For landing.  I had to update one comment that was out of date in the test file.
Attachment #324079 - Attachment is obsolete: true
Pushed to mozilla-central:
Closed: 14 years ago
Flags: in-testsuite?
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [has patch][has review][can land]
Target Milestone: --- → Firefox 3.1a1
Shawn, I've taken a look at this part with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008070902 Minefield/3.1a1pre.

What I noticed is, that after dropping the network cable the download is still active. Is there any timeout definied? I waited a minute but there wasn't a switch to pause mode. After plugging in the cable again the download immediately continues. Shouldn't the download stay in pause mode as the bug is about?
Sorry my fault. After switching to offline mode the download is automatically paused => Verified.
Yeah, dropping the network connection doesn't always make us go into offline mode, sadly.  But when it does, we'll be ready!
Product: Firefox → Toolkit
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Attachment #328564 - Flags: approval1.9.0.3?
Flags: blocking1.9.1? → blocking1.9.1+
Comment on attachment 328564 [details] [diff] [review]

Does not appear to meet 1.9.0 branch criteria, not approved. Thanks for the trunk fix!
Attachment #328564 - Flags: approval1.9.0.4? → approval1.9.0.4-
Flags: wanted1.9.0.x+
You need to log in before you can comment on or make changes to this bug.