When I failed over to the complete update, the UI went straight from the problem page to offering to restart, without showing the download page. Steps to reproduce, 1, take yesterday's nightly build, I was using the linux 32bit from 2010-03-22, mozilla-central 2, unpack, new profile etc 3, Help > Check for Updates, download partial, "Restart Later" 4, modify updates/0/update.status to say "failed: 6" with a newline 5, restart firefox At this point there is a 'Software Update' dialog (not on top) with the message 'The partial Update could not be applied. Minefield will try again by downloading a complete Update.'. On pushing the OK button the dialog proceeds straight to 'The update will be installed next time Minefield starts. You can restart Minefield now, or continue working and restart later'. Meanwhile the Help menu has 'Downloading Minefield 3.7a4pre' and I can see updates/0/update.mar getting bigger in 300KB chunks. If I restart before the d/l is finished there is no UI for applying the update, or a dialog reporting failure. Applies OK if I wait for the d/l to finish. Can't reproduce with yesterdays Firefox 3.6.3pre nightly, so probably this isn't present in 3.6.2. Haven't tried other platforms.

I've ended up in this condition before as has QA many times when manually trying to simulate a failure. I have mochitest chrome tests for this and will manually verify myself to see if I can reproduce. Now that I noticed that you are testing with 3.6.2 I suspect this might very well already be fixed on trunk where I've landed several fixes to bugs that have been around since app update was first implemented (see bug 530872). Nick, can you check if you can reproduce on trunk? Thanks

Rob, the main report is for updating the 2010-03-22 trunk nightly. The 1.9.2 branch info is supplementary.

Just so you know I'm not ignoring this... I'm trying to reproduce.

Oh, I certainly don't discount that I might be doing step 4 wrong somehow.

Just tried this with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 1. Downloaded Firefox Setup 3.6.exe 2. Extracted it with 7-zip (didn't want another install) 3. copied the contents of the localized directory into the nonlocalized directory 4. launched firefox.exe 5. Help -> Check for Updates - downloaded partial - clicked restart later 6. Opened update.status and changed it from pending with a newline to failed: 6 with a newline. 7. launched firefox.exe 8. The Update Failed page was displayed. 9. Clicked next and the Downloading Update page was displayed. and so on with a successful update. I'll try with a Minefield nightly. Manually reproducing a failure has never been fun. It might be helpful to add a boolean pref named app.update.log with a value of true to see if it provides any details as to why this is failing for you.

I tried 3 times with 3.6.2 and wasn't able to reproduce but I was able to reproduce on trunk and I am quite sure this regressed on trunk by bug 530872. The PITA about testing the download page is the way it moves forward automatically to the last page which is why the test didn't catch it.

Quick update... I've rewritten the test to use https://developer.mozilla.org/En/Httpd.js/HTTP_server_for_unit_tests#Advanced_dynamic_response_creation_%28not_available_in_1.9.0%29 and it reproduces this bug. So, the mochitest chrome test should be able to cover this bug.

I'm going to run this through a few more tests before asking for review. Nick, I wasn't able to reproduce when going from 3.6 to 3.6.2. Could you check again and if it wasn't you ask the person to reply in this bug so I can track down what was going on there?

Comment on attachment 434488 [details] [diff] [review] patch rev1 here's hoping Dave has time to do this today.

Sorry if I mislead you but I don't have any evidence that 3.6 has this problem, either from my testing or a 3rd party. I just happened to notice the problem today with trunk, and the last line of comment #0 was me being paranoid about the main release branch. I didn't test updating _from_ 3.6.2, but it looks like bug 530872 didn't land on 1.9.2 yet.

No worries and thanks for catching this

Comment on attachment 434488 [details] [diff] [review] patch rev1 Looks ok, just a couple of things that might be better. >diff --git a/toolkit/mozapps/update/test/chrome/update.sjs b/toolkit/mozapps/update/test/chrome/update.sjs > >+ // When a mar download is started by the update service it can finish >+ // downloading before the ui has loaded. By specifying a serviceURL for the >+ // update patch that points to this file and has a slowDownloadMar param the >+ // mar will be downloaded asynchronously which will allow the ui to load >+ // before the download completes. >+ if (params.slowDownloadMar) { >+ response.processAsync(); >+ response.setHeader("Content-Length", "775"); Can you set this from the actual file size. >+ var marFile = AUS_Cc["@mozilla.org/file/directory_service;1"]. >+ getService(AUS_Ci.nsIProperties). >+ get("CurWorkD", AUS_Ci.nsILocalFile); Does do_get_file not work here? >+ var path = URL_PATH + "empty.mar"; >+ var pathParts = path.split("/"); >+ for(var i = 0; i < pathParts.length; ++i) >+ marFile.append(pathParts[i]); >+ var contents = readFileBytes(marFile); >+ var timer = AUS_Cc["@mozilla.org/timer;1"]. >+ createInstance(AUS_Ci.nsITimer); >+ timer.initWithCallback(function() { >+ response.write(contents); >+ response.finish(); >+ }, 2000, AUS_Ci.nsITimer.TYPE_ONE_SHOT); 2 seconds seems quite long, how about just 1?

Pushed to mozilla-central

I talked these over in person with Dave but I am going to add them here for the record. (In reply to comment #12) > ... > Can you set this from the actual file size. It can be done but there are several other places in the test where this file is not touched except through http where the 775 is hardcoded so I don't see any value in doing so. >... > Does do_get_file not work here? Not available in mochitest >... > 2 seconds seems quite long, how about just 1? I'm concerned with 1 second being intermittently too short when running the tests on debug builds which would cause oranges so I went with 2 seconds just to be safer.