1917317 - Upgrade fails and show `XULRunner - Error: Platform version <x.x.x.x> is not compatible with minVersion <x.x.x.x>`

Status: REOPENED

(Toolkit :: Application Update, defect, P3)

Description

[Sylvestre Ledru [:Sylvestre]]

According to
https://kb.mozillazine.org/Browser_will_not_start_up#XULRunner_error_after_an_update
https://support.mozilla.org/fr/kb/firefox-demarre-pas-trouver-solutions#w_xulrunner-error
it is a known issue
but it is quite cryptic and I could not find an existing bug for this issue (my father in law just had this issue with 127.0.2)

Comment 1

[Sylvestre Ledru [:Sylvestre]]

Attachment: Bug 1917317 - When Firefox has a broken install, suggests to reinstall the program r?mpohle

Currently, the error message is quite cryptic
XULRunner - Error: Platform version <x.x.x.x> is not compatible with minVersion <x.x.x.x>

And our doc suggests to reinstall:
https://kb.mozillazine.org/Browser_will_not_start_up#XULRunner_error_after_an_update
https://support.mozilla.org/fr/kb/firefox-demarre-pas-trouver-solutions#w_xulrunner-error

Comment 2

[Max Christian Pohle [:/dev/max]]

Hi Sylvestre! In the end of our support.mozilla.org pages there is a "perma"-link capable "Share this article" link, which has the advantage to redirect to any language version of the same document.

https://support.mozilla.org/fr/kb/firefox-demarre-pas-trouver-solutions#w_xulrunner-error -> http://mzl.la/1xKrNIw#w_xulrunner-error

Do you have an idea what caused this issue or can you explain what you did before you got this error message? Which type of installation do you have and do you use background updates?

I like your idea to add the instructive text.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

TIL about support.m.o

And no, I don't have access to the system, sorry :(
It is on a Windows

About the message improvement:
https://phabricator.services.mozilla.com/D221348

Comment 4

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

For context, this problem generally happens when the updater screws up and also fails to roll back the failed update. I've seen a few logs of this happening, and it's not particularly clear what the cause is, nor does anyone seem to be able to consistently reproduce the problem. My best theories are 1) that two instances of the updater end up running at once and conflicting with each other or 2) antivirus. I've heard a theory that the updater could be exiting successfully but then the OS never fully writes the file to the disk causing an bad shutdown to result in data loss. From the accounts of this problem that I've heard, I think this is unlikely to be the typical reason that this happens.

When we finish our work on Bug 1891600, I believe that this is one of the problems that it should help address.

Comment 5

[Phabricator Automation]

Comment on attachment 9423272 [details]
Bug 1917317 - When Firefox has a broken install, suggests to reinstall the program r?mpohle

Revision D221348 was moved to bug 1917358. Setting attachment 9423272 [details] to obsolete.

Comment 6

[Max Christian Pohle [:/dev/max]]

I have discussed this bug in our weekly triage meeting and we came to conclude that its not worth to spend effort on it for two reasons:

1. The planned versioned update directory feature (see Bug 1891600) is going to make the update process so much more stable, that this issue becomes very unlikely to occur ever again after its implemented.
2. We are not sure if the error telemetry will ever reach us. It could also be saved to the profile directory and only send after Firefox gets relaunched with that same profile, which does not happen if Firefox gets reinstalled shortly after and does not start meanwhile.

For these reasons I am closing this bug now.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

I'm going to reopen this for 3 reasons:

1. "We will rewrite this code soon" is never, ever a reason not to take a fix (or in this case, a defect probe), because rewrites always take longer than you think, other stuff gets prioritized on top of it to make it take even longer, and shipping a large update for something as critical as the updater isn't going to be easy or fast either.
2. Having Telemetry would allow you to verify that the assumption in (1) is actually true and that your fixes worked and were worth the time and effort to implement.
3. The reasoning in point 2 makes no sense to me: why would a reinstall of Firefox not cause Firefox to be launched with the same profile afterwards? Unless the user explicitly erases all their data (a non-standard option and nonsensical behavior in this case!), you will still get the same profile after reinstall, no? Lastly, the pingsender infrastructure is being moved to the crash reporter (https://bugzilla.mozilla.org/show_bug.cgi?id=1901326#c6) so we probably do have options to send Telemetry like this in case Firefox itself gets totally busted.

This is a very serious issue that we know happened in the field only because users reach out via social media about it. To say it's not worth a telemetry probe sounds strange at least.

Comment 8

[Max Christian Pohle [:/dev/max]]

Thanks for that! I agree with your argumentation and think we should keep it on our triage radar until it gets fixed and we can link a closed bug that really fixes the issue and hopefully we will find a way to send emergency telemetry in cases in which the installation is completely broken. The crash reporter could potentially be expanded or forked for that, I guess.

Comment 9

[Max Christian Pohle [:/dev/max]]

I am going to assign this bug a severiety of S2 because its very serious and I will assign it a P3. I think that will suffice so that it keeps showing up in our triage center.

Comment 10

[Max Christian Pohle [:/dev/max]]

Sylvestre: I think to make this work we have to unassign you from actively working on it. Is that okay for you?

Comment 11

[Sylvestre Ledru [:Sylvestre]]

I was just updating the error message. not planning to do anything else :)
thanks