1881536 - Firefox does not start if using a profile created with a version of Firefox and opened with a older one (Nightly-Beta-Release)

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Bogdan Maris, Desktop Test Engineering]

Attachment: Screencast showing the issue

Found in

• Firefox 124.0b2

Affected versions

• Firefox 124.0b2
• Firefox 123.0
• Nightly 125.0a1 (I assume Nightly is affected as well, not able to check that)
• Firefox 122.0

Tested platforms

• Affected platforms: macOS 13.6
• Unaffected platforms: Windows 11, Ubuntu 22.04

Preconditions

• Have at least two different Firefox versions installed (unzipped), ex: Nightly-Beta-Release

Steps to reproduce

1. Start Firefox 124.0 beta with a new profile and change the value of a pref (browser.search.region for example from RO to US for me)
2. Close the browser
3. Open Firefox 123.0 RC with the same profile created when starting 124

Expected result

• A message is displayed saying that this is an older version of Firefox and this can corrupt bookmarks and bookmarks history saved in this profile giving the user the options to Exit or Create a new profile.

Actual result

• The old version Firefox message is not displayed, Firefox does not start but a firefox process is started in Activity monitor and is using 100% of CPU

Regression range

• I think this is a regression since ESR is not affected by this but not a recent one since Firefox 122.0 is affected. I will try and fine a regression range ASAP, but it will take a bit of time giving the nature of the bug.

Additional notes

• On Windows 11 and Ubuntu 22.04 the Old version message is correctly displayed and the firefox process that is started does not use an absurd amount of resources.
• Using the --allow-downgrade argument to start Firefox, will cause any Firefox version I use to start normally, this is used to bypass the Old Version message.

Comment 1

[Bogdan Maris, Desktop Test Engineering]

After digging a bit more and testing on RC builds:

• profile created in Fx 122.0.1 - opened with Fx 121.0.1 - FAIL (reproducible)
• profile created in Fx 122.0.1 - opened with Fx 121.0 - FAIL (reproducible)
• profile created in Fx 122.0.1 - opened with Fx 121.0b1 - FAIL (reproducible)
• profile created in Fx 121.0.1 - opened with Fx 120.0.1 - PASS (not reproducible)
• profile created in Fx 121.0.1 - opened with Fx 120.0 - PASS (not reproducible)

Based on the above and the fact that Fx 115.8.0esr does not experience this issue I think this means that there is something wrong with the build that is used to open the profile and not the build that creates the profile. Thus this issue appeared in Fx 121 build. Will need to dig up a bit more on this. These 665 issues are the ones that landed in Firefox 121.0b1.

Comment 2

[Bogdan Maris, Desktop Test Engineering]

I finally managed to test on mozilla-central branch manually and I found the following regressionrange https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4024630f5ffa1704a32f70c816f1003b0af9f105&tochange=ec7d4cb306bc811361cffc0253b35ff2385ae376, I think bug 1845407 might be a good candidate to be the culprit for this issue here.
Eitan can you please take a look at this?

Comment 3

[Eitan Isaacson [:eeejay]]

The fix in bug 1866098 should have fixed this regression. I'll take a look at this soon to see why this is still an issue.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Any updates on this, eeejay? We're in the last week of the 125 cycle if we wanted to come up with an upliftable fix.

Comment 6

[Dave Townsend [:mossop]]

Bumping up the severity here as this gives you a broken build that is hard for the average user to recover from. What is the status on getting a fix for this?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

This was also causing problems for Nick when we were trying to troubleshoot the recent macOS update failure incident.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Eitan, any luck with this? Is there any support that might help (ie testing, or something else?)

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Bogdan Maris, Desktop QA from comment #0)

Steps to reproduce

1. Start Firefox 124.0 beta with a new profile and change the value of a pref (browser.search.region for example from RO to US for me)
2. Close the browser
3. Open Firefox 123.0 RC with the same profile created when starting 124

Do we know if this affects newer browser versions as well, or does the 'older version' here have to be 123-or-older?

If this is specific to older-versions 123-or-lower, then this might become less relevant as those versions get further out of support range and less-conceivably-things-that-users-might-run.

(Having said that: version 115esr is still supported of course; so if this affects current-version-to-115esr downgrades, then that's an important data point.)

Comment 10

[Bogdan Maris, Desktop Test Engineering]

Attachment: Old profile prompt

(In reply to Daniel Holbert [:dholbert] from comment #9)

(In reply to Bogdan Maris, Desktop QA from comment #0)

Steps to reproduce

1. Start Firefox 124.0 beta with a new profile and change the value of a pref (browser.search.region for example from RO to US for me)
2. Close the browser
3. Open Firefox 123.0 RC with the same profile created when starting 124

Do we know if this affects newer browser versions as well, or does the 'older version' here have to be 123-or-older?

If this is specific to older-versions 123-or-lower, then this might become less relevant as those versions get further out of support range and less-conceivably-things-that-users-might-run.

(Having said that: version 115esr is still supported of course; so if this affects current-version-to-115esr downgrades, then that's an important data point.)

What I meant by older is that you need to use 2 Firefox builds, one that is older than the other, or different versions, lets say Nightly 128 and Beta 127. Create a profile on Nightly 128 and use the same profile on Beta 127.

For example I just reproduced using todays Nightly 128.0a1 and an older Nightly 127.0a1 so that the prompt saying "You've launched an older version of Firefox" will appear. In this case the prompt will NOT appear and so the process is stuck at 100%.

I tried using the latest ESR 115.11 and an older one 115.0 but the prompt is not triggered since they have the same version. I did used an older ESR 102.15 but the prompt will pe prompted and so the process is not stuck so this issue is not reproducible on ESR.

The workaround is to use the --allow-downgrade variable when starting the "older" Firefox (Nightly 127.0a1 in the above case) with the profile created with the "newer" Firefox (Nightly 128.0a1 in the above case).

Let me know if more clarification is needed, or more testing, happy to help.

Comment 11

[Eitan Isaacson [:eeejay]]

Finally able to reproduce, thanks for the clarification.

Comment 12

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1881536 - Call InitializeMacApp before CheckDowngrade dialog. r?spohl

We don't move the InitializeMacApp call earlier in this function outside of the isDowngrade branch because that impacted performance (bug 1876059).

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/172b26b3774b
Call InitializeMacApp before CheckDowngrade dialog. r=spohl

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/172b26b3774b

Comment 15

[Bogdan Maris, Desktop Test Engineering]

Adding a needinfo for myself to verify that this is fixed when a new version is available (>=129) since at this time I don't know of a way to verify it due to the nature of it.

Comment 16

[Bogdan Maris, Desktop Test Engineering]

I am unable to reproduce this bug with builds after the fix in the following configurations:

• creating a profile using the Latest Nightly 129.0a1 -> opening the same profile with Nightly 128.0a1 after the fix (2024-05-30)
• creating a profile using the Latest Nightly 129.0a1 -> opening the same profile with Beta 128.b3

For the above configurations the "old version" prompt is displayed and the process is not stuck. Closing as verified fixed.