19
edits
Changes
m
→The Plan: typo
Use a XPI-like package to deliver the update. The update itself will contain a manifest of files which need updating/removal. The update may happen once the download is complete, at app shutdown, or the next time Firefox is launched. That behavior is a policy decision to be decided upon by the user-facing update service.
The application must not be running while the update is being installed. Our systems, including the JAR cache, are not designed to deal with changes to their underlying files. In addition, the Windows filesystem does not allow files to be unlinked from their parent directory while they are in use. The Firefox executable will run a separate update binary (using execv or another method). This executable will process the update manifest and may leverage the binary patching technology of [http://www.daemonology.net/bsdiff/ bsdiff] (with modifications for reliability). Once the update executable completes, it will re-launch the Firefoxs Firefox executable. This will allow Firefox to perform any post-upgrade operations (e.g., modifying registry keys, etc.).
Users will have the option to view silent upgrade progress, and choose to cancel, suspend, or "complete it now." They will also be provided with simple controls to alter the upgrade policy (notifications, silent or not, etc.).
