Confirm, emeritus
1,217
edits
Changes
→The Plan
Use XPIs to deliver the update. The update itself will be an executable that will be run by Firefox when it detects that a XPI has been fully downloaded. This may happen once the download is complete, at app shutdown, or the next time Firefox is launched. That behavior is a policy decision yet to be decided upon. Using XPIs to deliver the update executable allows us to leverage the existing support for signed XPIs. Moreover, we have the option of packaging an entire install executable in the XPI if that is deemed appropriate.
<table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;">
<tr><td>
bsmedberg says: Why is the update a separate executable? What we would need to add to xpinstall is
# Binary-patch functionality
# Ability to do the xpinstall at shutdown/startup (not now)
Since we're planning on coding these features anyway, let's do it right! I can't see that it would take a lot more time than creating separate update executables for each update.
</table>
The Windows filesystem does not allow files to be unlinked from their parent directory while they are in use. This means that we have to shutdown Firefox before updating it. The update executable will wait for Firefox to shutdown before it begins updating Firefox. It may either replace individual files or leverage binary patching (see [http://www.daemonology.net/bsdiff/ bsdiff]) to update Firefox. Once the update executable completes, it will launch Firefox passing it a command line flag to instruct Firefox that it has just been updated. This will allow Firefox to perform any post upgrade steps (e.g., modifying registry keys, etc.).
