User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050105 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050105 Minefield/3.0pre If my nightly build is set to autoupdate settings, and left idle for a day, i will get two notifications to AUS twice. However, one update dialog says "Minefield 3.0pre" while the following reboot > check for updates will quickly say "Minefield 3.0pre 200805.... nightly" See screenshots. Reproducible: Always Steps to Reproduce: 1. Set your nightly build to "Automatically install the update" when an update is available. 2. Leave computer and browser running overnight 3. Check the next day when a nightly is available, and notice the update dialog says "Minefield 3.0pre" 4. Restart minefield button with the update 5. After restart, go to Help > Check for updates 6. Verify a new update dialog appears, saying "Minefield 3.0 200805..... nightly" is available Actual Results: Should not have 2 update dialog windows. Should only be one, which is the latest nightly. Expected Results: 2 update dialog windows. see screenshot.

Minefield nightly Update screenshot

Minefield 3.0pre Update screenshot

I think this is the desired behavior. 1) running day 0 nightly, and day 1 nightly becomes available 2) day 1 nightly is downloaded, but not installed yet 3) day 2 nightly becomes available, but because day 1 nightly is still waiting to be installed, it is not downloaded 4) day 1 nightly is finally installed 5) now running day 1 nightly, and an update check prompts you to download day 2 nightly This is desired in the sense that it will let you get to the day 2 nightly with two partial updates, saving you from having to do a full update. (OTOH, if you wait long enough, and it becomes a day >2 nightly, then you'll end up doing a partial and a full). So the issue really is with (3), where a new update won't download if the previous update is still awaiting install. As for the naming, that's just an inconsistency with the two different dialogs: it doesn't display the build date for the dialog that shows for updates that have downloaded and are awaiting install, and it does display the build date for the dialog that shows for updates that haven't even been downloaded yet.

That's a good analysis Kai. The only thing I'd add is that the update settings are not at all optimised for nightly builds, eg the interval between background update queries is 24 hours (not sure how restarts affect this). The combination of that interval, "trickle" downloads, and the updater not blowing away an update if a newer one is available (3), makes it easy to get into state Tony describes.

that makes sense now. which is why someone on the release channel will never see the partial/complete update scenario like this. Is there anything we can do for the 3rd scenario, where we skip the idle update and jump directly to the latest complete nightly? And There probably isnt anything we can do with the naming inconsistency on nightlies right?

Users on the release channel are affected too. Having not the appropriate permissions to install the update will cause the update to hang around until Firefox is started by an administrator the next time. And this can take a while... I filed such a bug a long time ago. And this one seems highly to be a dupe of mine. See bug 353804 for further details.

Same bug just different steps to reproduce... I suspect there are more if you are up for going through and duping them all to one bug.

(In reply to comment #0) > > If my nightly build is set to autoupdate settings, and left idle for a day, i > will get two notifications to AUS twice. However, one update dialog says > "Minefield 3.0pre" while the following reboot > check for updates will quickly > say "Minefield 3.0pre 200805.... nightly" The first dialog is to inform you that a restart is necessary to install the already downloaded update. The second after you have restarted is to inform you that there is a new update available. I'm not sure that there is better behavior for your specific case. The update has already been downloaded and is ready to install when a new update is also available. If we cancel the pending install we will end up downloading a complete update for every complete update that becomes available and is set to pending install. Reopening since this isn't the same as bug 353804.

The UI related to this is no longer used by Firefox. Closing old bugs as incomplete. If this is still an issue please file a new bug.