This issue can easily be reproduced with current trunk builds: 1. Download and install a nightly build which is at least two days old 2. Start Firefox and go to "Check for Updates". 3. Start downloading the full package. 4. Close Firefox before the download has finished. 5. Restart Firefox Now the help menu states that the update is currently downloading but no download is started. You can wait forever and won't get any updates until you manually open the software update dialog. Then the download continues. Asking for blocking because this can prevent users from getting any update. This bug causes bug 353804 which I filed a while ago and happens for trunk and 1.8 branch builds.

Any progress / ETA on that one? Beta3 is over...

I've noticed a strange behavior which could probably fall into this bug report. I had the same situation today. Firefox needed a restart while the download was running. Afterwards the download stalls. I've taken a look inside the updates folder, to see how many bytes Firefox downloads at all. So here my findings: On each start of Firefox exactly 300.000 bytes are downloaded. Afterwards the download stalls for the whole session. I can repeat this (reproducible) in doing restarts one after another. The file size of udpdate.mar grows with 300.000 bytes each time. This is marked as blocking-firefox3. Are there any plans how to fix this problem?

Haven't seen other reports of this, and updates seem to be working in general, so not going to block, but we should find out what's causing this and fix it in a point release.

Mconnor, most users will not see this bug because the incremental updates are small and even quickly downloaded when using a slow internet connection. But think about full .mar packages. Normally it takes to one minute or more with a broadband connection to download the update. If you shutdown Firefox while such a download is running in the background, it will not continue after the restart. You see "Downloading..." inside the Help menu but that never changes its state. I see this on several boxes running WinXP or OS X.

Another user who reported bug 431232 probably also have seen this issue.

This bug always happens to me each day on each platform/OS. I'm a bit surprised that no-one else is affected by this issue.

I've tried reproducing with Shiretoko, Minefield, Thunderbird, and Sunbird without success. With app.update.log.all = true I get the following in the console on startup after exiting while an update is being downloaded AUS:SVC Downloader:_selectPatch - found existing patch with state: downloading AUS:SVC Downloader:_selectPatch - resuming download AUS:SVC Downloader:downloadUpdate - downloading from http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/2009/02/2009-02-10-05-comm-central-sunbird/sunbird-1.0pre.en-US.win32.complete.mar to C:\Users\Robert\AppData\Local\Mozilla\Sunbird\Calendar\updates\0\update.mar AUS:SVC Downloader:onStartRequest - spec: http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/2009/02/2009-02-10-05-comm-central-sunbird/sunbird-1.0pre.en-US.win32.complete.mar AUS:SVC Downloader.onProgress:onProgress - progress: 300000/9223470 and several minutes later the next hunk AUS:SVC Downloader.onProgress:onProgress - progress: 600000/9223470 For history on the reason updates download so slowly in the background see bug 352853 and bug 353182

I wonder if the XHR bug could be causing these syptoms for you...

I tried it again but the download doesn't continue even when it is stated in the log: AUS:SVC Downloader:_selectPatch - resuming download AUS:SVC Downloader:downloadUpdate - downloading from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/02/2009-02-10-09-mozilla-1.9.1/firefox-3.1b3pre.en-US.win32.complete.mar to C:\mozilla\bin\a\updates\0\update.mar AUS:SVC Downloader:onStartRequest - spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/02/2009-02-10-09-mozilla-1.9.1/firefox-3.1b3pre.en-US.win32.complete.mar AUS:SVC Downloader.onProgress:onProgress - progress: 6900000/10209705 After the last entry nothing is added anymore to the Error Console. I've been waiting for a couple of minutes without any change. After a restart I definitely have a progress since the last time: AUS:SVC Downloader.onProgress:onProgress - progress: 7200000/10209705 But it stops again. We can meet up so I can show you the behavior directly.

Try waiting well over 600 seconds since that is what bug 352853 changed it to be

patience grasshopper

Ok, I've waited half an hour now and nothing changes. The menu entry under help still states "Downloading..." but there is no progress at all.

Did you receive any more of the AUS:SVC Downloader.onProgress:onProgress - progress: messages (I did with all apps)? Do you have any idea what is different about your system vs. others that would cause this for you?

No, thats the only message I get within a session. There is no more coming up. I have no idea about the second question. I'm still able to reproduce it on other systems. So it shouldn't be machine related. Are you in the office today? I could come over to building s (right?).

Go ahead and put one of the qa systems over in bldg k into this state with the app.update.log.all pref set to true and I'll come over and take a look this afternoon.

Henrik, you and I tested out the background download case when the "Pause" button hasn't been pressed and found that it does work as I stated in comment #8. When I saw how you were reproducing by pressing the "Pause" button I assumed that there might be a bug in that instance... thing is, that also works for me as I stated in comment #8. Can you try again to reproduce using the "Pause" button and please be sure to wait the 10 minutes? Thanks

I just tried a bunch of different ways to reproduce this when using pause and was unable to reproduce. I suspect that you may be mistaken just like you thought it didn't continue to download in the background without using the pause button along with not waiting long enough to actually see that it is downloading via the console.

Sure, I can do that. Is there any way to reduce the interval? That would make it easier for me.

Not yet... I am making it configurable by a pref in Bug 477908 but I don't know when I will land that. All you have to do is wait ten or eleven minutes which isn't that difficult... I've done it several times myself trying to reproduce this bug.

Henrik, have you had a chance to check yet?

Yes, I tried to reproduce it several times but failed all the time. I've one last scenario I'll check. If this also works I'll mark this bug as WFM for now. I hope that I'll find the time tomorrow.

Henrik, have you checked the one last scenario?

Resolving -> WFM. If you can reproduce please reopen with info on how to reproduce. Thanks

Haven't seen it all the last time. I will report back if I should see it again. Thanks Rob.