Closed Bug 1152027 Opened 9 years ago Closed 5 years ago

Don't lose users to persistent startup crashes after browser update

Categories

(Toolkit :: Startup and Profile System, defect)

All
Windows
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: vladan, Unassigned)

References

Details

Ehsan and I were discussing the startup crash in bug 1149761, and we came up with an approach that would save users from persistent startup crashes caused by an upgrade.

The problem:
=========================

If a user updates to a new Firefox version and this new version causes persistent startup crashes on their system (even in safe-mode), the user will never be able to run Firefox again on that system even if we release a new, fixed version of Firefox. The updater service does not install the new version.

The user is lost for good unless they manually download & install a fixed version using a different browser. They would still have to wait until that fixed version becomes available. Obviously, most users would just switch to a different browser. 

Therefore, persistent release-channel startup crashes are a source of user loss even if the crashes get noticed and fixed very quickly.

The proposal:
=========================

After a new update has been staged, firefox.exe invokes updater.exe on next startup to perform a "switcheroo" of the directories containing the old and new Firefox versions and then restarts itself to the new Firefox version. updater.exe also deletes the directory with the old Firefox version.

Instead, Firefox should keep the old directory around. If the new Firefox version crashes on startup, the crash reporter can check if this was a safe-mode startup crash caused by a new Firefox version. It can then invoke updater.exe to restore the directory with the previous Firefox version and delete the directory containing the new, faulty version. Additionally, it should either modify update.status or create a file somewhere else to indicate that the new version is bad and that it should not install an update again until a newer version becomes available.

Alternatives considered:
=========================

1. Have the Mozilla Update Service download and install new versions on its own: 

Rejected because we wouldn't want to to add complexity to the update service and we wouldn't want to wait until a new version is available to restore Firefox to a working state. We also don't want make radical changes to updater.exe.  Also since the maintenance service doesn't exist on non-Windows platforms, this would basically mean having two different code paths for downloading updates.

2. Run the new version from an alternative directory until it has proven itself stable: 

Rejected because this might mess up user extensions or shortcuts that rely on a constant Firefox path or the binary extensions that have themselves installed into our application dir.

Other considerations:
=========================

There are cases where we would want the user to abandon Firefox and switch to another browser. We wouldn't want a user to get stranded on an old, insecure version of Firefox forever if we're never going to fix the startup crash. We have existing safeties in Firefox that prompt the user to manually download a new Firefox if their current version is too out of date. If the user ends up stranded on an ancient version of Firefox and manually installs a new version (with the crash unresolved), they will have overridden this proposed fallback mechanism.
We could leave an 'old' directory around but the majority of the work would need to be in startup code where the code would need to determine that Firefox is crashing and use that instead.
Component: Application Update → Startup and Profile System
Depends on: 1152030
Please note that staging is not required to update and isn't always used when updating. Also, staging will not be performed on Windows for the non maintenance service update process case to solve a couple of security issues. Doing this during staging will also slow down updating.

Another option would be to have the app perform the copy immediately after an update. This way if the user has the correct rights to copy the dir the app can use cross platform code to make the copy. On Windows the app can call the maintenance service to perform the copy. This is assuming that the copy must be somewhere under Program Files and if that isn't a requirement then the maintenance service doesn't need to be involved.
See Also: → 1524778
See Also: 1524778

I spent some time looking into the idea of keeping an old version of Firefox around to fallback to. Unfortunately, we have decided that such a project would be very difficult and would have a number of undesirable drawbacks. Ultimately, there are other projects we can work on that would give more user benefit for the effort required.

Some of the more unpleasant drawbacks of this approach are:

  • It would be difficult (maybe impossible) to prevent downgrade attacks from malware with local access
  • Fallback to a previous version would end up hitting profile downgrade protection, causing the user to fall back with no profile.

A summary of the findings can be found here.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.