See bug 436382 comment 17

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)

work in progress. Test case crashes right now, but I think it's because I'm toggling offline state inside the listener.

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.

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.

I filed bug 438040 for necko, and bug 438042 for the download manager

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.

I'll push my own bugs - thanks!

For landing. I had to update one comment that was out of date in the test file.

Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/index.cgi/rev/a7a2c2589b2a

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!

Comment on attachment 328564 [details] [diff] [review] v1.1 Does not appear to meet 1.9.0 branch criteria, not approved. Thanks for the trunk fix!