1868951 - Failed update causes a "XULRunner" modal message box saying the platform version is not compatible

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[Florian Quèze [:florian]]

Attachment: failed update.png

See attached screenshot. This happened after Firefox restarted for an update. The user thought there was a virus on the computer, and would most likely have switched to another browser if I wasn't here to help.

The message comes from https://searchfox.org/mozilla-central/rev/23e7e940337d0e0b29aabe0080e4992d3860c940/toolkit/xre/nsAppRunner.cpp#4097

Comment 1

[Florian Quèze [:florian]]

The 'XULRunner' string comes from https://searchfox.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#489

Comment 2

[Florian Quèze [:florian]]

We should probably change the message to suggest reinstalling the application, as unless the user has been intentionally editing the application.ini file, the only way to end up with such a message is a corrupted installation after a failed update.

Comment 3

[Florian Quèze [:florian]]

Then after reinstalling Firefox, at the next restart, the screen remains blank for 30s, which is bug 1749345. That makes for a very poor user experience.

Comment 4

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Pascal Chevrel (relman team) -> :pascalc|PTO until Sept 2]

Dave, any update on this issue? We are still getting reports on SUMO about it. Thanks!

Comment 8

[Dave Townsend [:mossop]]

There isn't a great deal that we can do from the startup side of things. If we're in this state it means that firefox.exe and xul.dll are out of sync with each other (in the screenshot example xul.dll is from a newer version than firefox.exe). We could just try carrying on regardless, firefox.exe isn't responsible for much beyond launching Gecko, but if firefox.exe is wrong what else in the install directory might be wrong?

We could change the wording of the dialog, perhaps even do something like launch another browser pointing to our download page, but localization would be very hard.

The ideal solution is to solve this on the updater side of things so we don't end up in this state in the first place. Bug 1891600 is one avenue that should help, I don't know if there is anything else we can do on the updater side of things, maybe Robin has thoughts.

Comment 9

[Florian Quèze [:florian]]

(In reply to Dave Townsend [:mossop] from comment #8)

We could change the wording of the dialog,

There was a recent improvement to the wording landed in bug 1917358.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

We decided to ignore the l10n issue as it is still an improvement over the current situation

Comment 11

[Robin Steuber (she/her) [:bytesized]]

(In reply to Dave Townsend [:mossop] from comment #8)

We could change the wording of the dialog, perhaps even do something like launch another browser pointing to our download page, but localization would be very hard.

Yeah, as already mentioned, we did change the wording, but it's still not ideal for a number of reasons including lack of localization.

The ideal solution is to solve this on the updater side of things so we don't end up in this state in the first place. Bug 1891600 is one avenue that should help, I don't know if there is anything else we can do on the updater side of things, maybe Robin has thoughts.

Bug 1891600 is definitely my preferred way of fixing it. Unfortunately, this will still leave macOS still potentially suffering from this problem and there is not currently a timeline for fixing that (though it's definitely on my wishlist). To be clear, I have never actually gotten a report of this happening on macOS. I have been assuming that that's largely just sampling bias since we have way more Windows users. But it's possible that this is a Windows-specific problem, especially since we don't definitively know the underlying cause of the failure to update and the failure to roll back. One of the theories is antivirus, which would definitely skew way towards Windows.

If we want to address this in another way, there are 2 things I know of that we could do. We could remove support for updating "in-place" and always update via staging, even when we are applying the update at startup. This would greatly improve the chances that we could roll back properly on errors since none of the original files would be modified until the very end of the process when we do the replace request. We could also add some system API calls to the end of update to force the OS to write the changes to the disk immediately rather than potentially caching them. Though I only have any idea what that API looks like on Windows.

Ideally, if we pursue this, we should also add a way of identifying errors due to lack of disk space and communicating that to the user. At the moment, such errors are just identified as general write errors. One of the ways that we fall back from this sort of error is to install the update in-place rather than using staging. This is done, in part, because staging involves making a whole extra copy of the installation and thus requires extra hard drive space.