Updating Firefox in the Background

The dialog below should look familiar. It displays while Firefox completes the update process after a new version is installed and the browser is restarted.

Firefox Update Dialog

In order to update itself, Firefox first starts to download an update in the background. When the update is downloaded, Firefox stages it in a directory ready to be applied. The next time that Firefox is about to start up, it checks out the staging directory. If an update ready to be applied is found, Firefox launches the updater program, and applies the update on top of the existing installation (showing that progress bar as it’s doing its job). When the update process is finished, the updater program restarts Firefox. All of this happens as you’re waiting for your browser to start up in order to do what you wanted to do. This is clearly less than ideal.

For the past few weeks, I have been working on a project to improve this process. The goal of my project is to minimize the amount of time it takes for Firefox to launch after downloading an update. The technical details of how I’m fixing this problem can be found this document. Here’s a short version of how the fix works. When Firefox finishes downloading an update, it launches the updater application in the background without displaying any UI, and applies the update in a new directory that is completely separate from the existing installation directory. Instead of staging the update itself, an entire updated version of Firefox is staged. The next time that Firefox starts up, the existing installation is swapped with the new updated installation which is ready to be used. In this scenario, you likely won’t notice that Firefox has applied an update as no UI is shown.

Now, the reason that this approach fixes the problem is that swapping the directories, unlike the actual process of applying the update, is really fast. We are effectively moving the cost of applying the update to right after the update has been downloaded while the browser is running. This leaves only the really fast copy operation to be performed the next time that the browser starts up.

I have some experimental builds with this feature ready in a temporary channel called Ash. The implementation is now at a stage where it can benefit testing from the community. You can download the latest builds here. I will trigger a few nightly builds on this branch every day so that you would get updates if you’re running an Ash build.

In order to help with testing this new update process, all you need to do is to download the latest build from Ash, then wait a few hours so that a new nightly build becomes available, and then update to that build. Updating can be triggered manually by opening the About dialog, or by the background update checker if you leave the build running for a few hours. If everything works correctly, when you restart Firefox, you should get a new build without seeing any progress bar as Firefox is starting up. In order to verify that you have indeed been updated to a new build, you can go to about:buildconfig, copy its contents, and then compare it with the contents of about:buildconfig when Firefox starts up after an update.

It would be extremely useful if you can test this with different types of security and anti-virus software running. If you observe any problems or warning, or if you see that the update did not change the contents of about:buildconfig, then please let me know so that I can try to fix those problems.

For people who are curious to see the code, I’m doing my development on this branch, and I’m regularly posting patches on bug 307181.

Please note that this is still in the testing stage, and at this point, we’re not quite sure which version of Firefox this will land in (we’re working to land it as soon as is safely possible). No matter which version of Firefox includes this feature for the first time, we believe that this will be a very positive change in making the Firefox update experience more streamlined for all of our users.

Posted in Blog Tagged with: , ,
26 comments on “Updating Firefox in the Background
  1. How does this account for the fact that there will be files in the installation directory that need to be maintained by the upgrade?

  2. Ehsan Akhgari says:

    The entire installation directory is copied over before being updated, so any such files should continue to be present in the updated version unless they’re explicitly removed by the updater, which is identical to the way that the current updater works.

  3. Visitor says:

    Does it take into consideration files that are current locked by the running process?

  4. Ehsan Akhgari says:

    Yes, it does.

  5. Visitor says:

    Can’t you apply the update when Firefox is closing instead of at the start?

  6. Ehsan Akhgari says:

    That is not really ideal, because it makes the shutdown process longer than it needs to be.  Think of the case where for example you shut down your computer, and your OS needs to wait for Firefox to shut down before it can proceed with turning the computer off.

  7. What happens if the update is downloaded, the directory is copied, and some other installer or an enterprise management policy install a new plugin or system add-on?, the copy loses the new installed add-on? (Installing new files while Firefox is running is not a problem because there aren’t files locked)

  8. Ehsan Akhgari says:

    If those files are copied into the installation directory after the update has been applied in the background, they will be lost the next time that Firefox starts up.  In general, writing files to an application’s installation directory while it’s running is a bad practice.  Do you know of any existing software which might be affected by this problem?

  9. Daniel Cater says:

    Without having read any of the stuff, I have 2 questions:

    Does this undo any of the fragmentation optimisations that were done for the current updater?

    Will there be an easy way for people to see when their build last updated? A timestamp in about:support would be nice.

  10. Ehsan Akhgari says:

    About fragmentation optimizations, I’m noit sure which ones you’re mentioning.

    About your second question, a complete update history is available in the Update tab in the Advanced pane of the Options window, and this will not change with my current work.

  11. Daniel Cater says:

    I was talking about https://bugzilla.mozilla.org/show_bug.cgi?id=570058 (fixed) and https://bugzilla.mozilla.org/show_bug.cgi?id=616390 (unfixed). It would be good if both of these could be taken into account. https://bugzilla.mozilla.org/show_bug.cgi?id=529464 (unfixed) also had some ideas, I don’t know if any of them would be relevant now.

  12. Ehsan Akhgari says:

    Good point, thanks for bringing it up.  I will investigate to make sure that my work doesn’t regress this.

  13. Lozzy says:

    I installed Ash yesterday and tried to update today. The partial update was met with an error and asked to try a full update, which applied instantly at startup as expected.

    This is possibly to do with Comodo, because when I updated Ash, Comodo notified me that the exe had changed and asked me to confirm, thus probably blocking the update in some manner. I’m going to keep tabs on it and try to reproduce it on the next update (could I get an update please?)

  14. Ehsan Akhgari says:

    Thanks a lot for helping to test this!  I just pushed a new version which should mean that there would be another update available for you in a few hours.  Please let me know if you experience the same problem again.

  15. […] Updating Firefox in the Background | Ehsan Akhgari […]

  16. Lozzy says:

    Thank you. This time the partial update completed successfully. I left Comodo’s settings the same and the did warning fire again, but didn’t seem to cause any problems. I’ll carry on testing different settings to see if anything else in Comodo might prevent it, but for the moment it seems like my previous error was a fluke.

  17. Ehsan Akhgari says:

    Do you see the same warning when you update other Firefox builds?  If no, I think we should investigate this.


    Thanks again for your help here!

  18. Lozzy says:

    I’ve been running Aurora since its inception and I don’t remember seeing any partial update errors while on that channel. At this point I’m entirely unsure what caused my earlier error, so it’s something that I’ll need to test more.

    Hopefully I can use the installer to roll Firefox back and update whenever I need. I’ve only just grabbed a copy of that installer though, so I’m afraid it’ll need another update beyond that.

  19. Lozzy says:

    Well, I’ve tried various permutations to try and recreate the first error (including using the most paranoid settings on Comodo possible and running in its sandbox), but it seems it was just an anomaly.

    Must say that I’m impressed with how much of an improvement this makes. It’s so quick and I couldn’t discern any performance loss during the process of applying the update (the one just after the update has been downloaded).

    I remember reading at some point that work was planned to mitigate that process so that it wouldn’t interrupt browsing, but from what I can tell it doesn’t seem necessary. Especially given that it only takes a few seconds at an interval of 6 weeks.

  20. Ehsan Akhgari says:

    We might still be able to optimize the process to make it even faster, but when all of this happens in the background, it has little chance to disrupt the user experience, so there is a lot of perceived performance gain associated with this work.

  21. Perhaps I’m missing something, but under most systems, won’t the directory Firefox is located in be write-protected (ex: C:\Program Files)? Preventing the folder-swapping process from occuring? Or will this be solved with the Firefox background service?

  22. Ehsan Akhgari says:

    If the Firefox update service is available, we’ll use that in order to swap the directories.  Otherwise, we’ll initiate a UAC prompt as we do today when Firefox starts up after an update has been installed in the background.

  23. When we’re talking about doing stuff in the background without a UI, is there any way interested people can still get some display that shows them while their disk is suddenly spinning a lot?

    Also, are we displaying some UI during manual update that shows people that the update is being applied? (I guess many people doing manual update just want to do the restart immediately after this all has finished, as they are watching the process.)

  24. Ehsan Akhgari says:

    It is possible for users to opt out of this new update experience, but we don’t want to display any UI when the update is being applied in the background, the same way that a lot of other interesting stuff happens in the background without displaying a UI.

    For manual updates that happen by the user opening the About dialog, they will see the progress of the update in the background, and they will get a Restart & Update button which lets them restart the browser immediately to finish the update process.

  25. Funtom says:

    If I understand it correctly, the described approach assumes the user running Firefox is the user that will run the updater and hence has the right to write to the install directory. Am I missing something or is this approach really this limited?
    Google’s approach, for example, is running the updater under the administration user any time the computer starts. Speaking of Winodws systems now. Thus, the new version is downloaded and installed without the need of running the application itself. I was expecting Mozilla to follow it. If Mozilla has considered the Google’s approach, what are the reason to steer clear of it?

  26. Ehsan Akhgari says:

    In addition to background updates, we are also working on another project to enable the update process to install an update even if the user does not have permission to write to the installation directory.  That is a parallel project to my work.  You can read more about it here.