When Firefox downloads an update, it previously kept the update around to apply
it on the next restart. This patch changes this so that the updater program
is launched in the background as soon as the update has finished downloading
in order to stage the updated version of the application by copying the
existing installation directory to a temporary location and applying the update
on top of it, and replace the existing installation directory with the staged
directory on the next restart.
Because the replacing step is typically very fast, this patch eliminates the
wait for the update to be applied on restart, making it unnecessary to show a
progress dialog when restarting.
--HG--
rename : toolkit/mozapps/update/test/chrome/test_0092_finishedBackground.xul => toolkit/mozapps/update/test/chrome/test_0093_stagedBackground.xul
rename : toolkit/mozapps/update/test/unit/test_0110_general.js => toolkit/mozapps/update/test/unit/test_0113_general.js
rename : toolkit/mozapps/update/test/unit/test_0111_general.js => toolkit/mozapps/update/test/unit/test_0114_general.js
rename : toolkit/mozapps/update/test/unit/test_0112_general.js => toolkit/mozapps/update/test/unit/test_0115_general.js
rename : toolkit/mozapps/update/test/unit/test_0170_fileLocked_xp_win_complete.js => toolkit/mozapps/update/test/unit/test_0172_fileLocked_xp_win_complete.js
rename : toolkit/mozapps/update/test/unit/test_0171_fileLocked_xp_win_partial.js => toolkit/mozapps/update/test/unit/test_0173_fileLocked_xp_win_partial.js
rename : toolkit/mozapps/update/test/unit/test_0110_general.js => toolkit/mozapps/update/test_svc/unit/test_0113_general_svc.js
rename : toolkit/mozapps/update/test/unit/test_0111_general.js => toolkit/mozapps/update/test_svc/unit/test_0114_general_svc.js
rename : toolkit/mozapps/update/test/unit/test_0112_general.js => toolkit/mozapps/update/test_svc/unit/test_0115_general_svc.js
rename : toolkit/mozapps/update/test/unit/test_0170_fileLocked_xp_win_complete.js => toolkit/mozapps/update/test_svc/unit/test_0172_fileLocked_xp_win_complete_svc.js
rename : toolkit/mozapps/update/test/unit/test_0171_fileLocked_xp_win_partial.js => toolkit/mozapps/update/test_svc/unit/test_0173_fileLocked_xp_win_partial_svc.js
This addresses an issue with the download manager that can cause high CPU usage
when there is an active download. The underlying issue is the frequency of
updates that the download progress listener receives.
Things changed:
- reduced the number of null checks in DownloadUtils.jsm's getDownloadStatus
function by one (down to two from three).
- obtain and format strings from the nsIStringBundle. This removes all the
calls to String.replace in DownloadUtils.jsm.
- modifies the download manager back-end to update the percentComplete and size
property on downloads before dispatching a state changed notification for
downloads entering the DOWNLOAD_DOWNLOADING state. This saves us two calls to
setAttribute on downloads that we know how big they are, and saves us the same
two calls to setAttribute for indeterminate downloads as well as not
dispatching a ValueChange event on the progressmeter every time
onProgressChange is called on the DownloadProgressListener.
- has nsDownload implement nsIClassInfo so we do not need to QueryInterface when
going through the list of active downloads in both the download manager's UI
and the browser's taskbar UI.
