2003137 - Running an old version of Firefox can break xdg-basedir support

Status: NEW

(Core :: XPCOM, defect, P2)

Description

[Emilio Cobos Álvarez [:emilio]]

If you use the new xdg-basedir support (~/.config/mozilla/firefox), it might be the case that running an older version of Firefox (for me it happened using Mozregression) breaks your current installation.

E.g., my current profile lives in /home/emilio/.config/mozilla/firefox/2dc63pys.default-nightly, so far so good.

If now I run a mozregression for an older version of Firefox, that will create a bunch of stuff in ~/.mozilla/firefox (unfortunate but expected). But the issue is, after that, launching nightly will not use my profile in ~/.config/mozilla/firefox!

It seems the logic right now goes like:

• If there's a legacy dir, use that.
• Otherwise use XDG basedir.

Instead, it should probably be:

• If there's an XDG basedir, use that.
• Otherwise, if there's a legacy dir, use that.
• Otherwise use XDG basedir.

I think that would work and be an improvement? Or am I missing something?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 259356

:gerard-majax, since you are the author of the regressor, bug 259356, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[:gerard-majax]

Someone else should handle this.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox147 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned.

:jstutte, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 4

[Jens Stutte [:jstutte]]

Would you be able to find some time (if it is an easy enough fix to squeeze it in) ?

Comment 5

[Thinker Li [:sinker]]

Hi gerard-majax,

May I know what the consideration is of preferring legacy directory instead of XDG basedir?

Comment 6

[:gerard-majax]

(In reply to Thinker Li [:sinker] from comment #5)

Hi gerard-majax,

May I know what the consideration is of preferring legacy directory instead of XDG basedir?

that was the assumption to no risk of breaking legacy setup

Comment 7

[Thinker Li [:sinker]]

I will fix mozregression to make sure that the legacy directory is removed if it didn't exist when mozregression started.

Comment 8

[Thinker Li [:sinker]]

Just found that you can pass the argument --profile to specify a profile dir for tests.
The default behavior of mozregression will create a new temp profile every time. Why do you still get a lot file created in ~/.mozilla/firefox?

Comment 9

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

Regardless, MozRegression should bypass this problem automatically: I had been advised to run MozRegression before I happened to find this issue, so this problem would have also impacted me if I hadn't.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Well, somewhat? But I ~never use it, 99% of the time you want a clean profile.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Here's a trivial STR:

• Back up and remove ~/.mozilla and ~/.config/mozilla.
• Launch nightly. Set a theme. That will create a profile like: /home/emilio/.config/mozilla/firefox/2dc63pys.default-nightly .
• Set a distinguishable theme or something. Close it.
• mach mozregression --launch 120 (or whatever version). Note that an alternative STR as of today would be to also open Firefox release or ESR.
• That uses a temporary profile, but creates a ~/.mozilla tree like this:

/home/emilio/.mozilla/firefox/
├── Crash Reports
│   ├── InstallTime20231023215318
│   └── events
└── Pending Pings

• Close the mozregression build.
• Open nightly again.

Instead of your profile in ~/.config/mozilla/firefox, you'll be greeted with a "first run" page (here). Profile in my case is /home/emilio/.mozilla/firefox/p3fwa119.default-nightly, which is the wrong directory.

Wiping the ~/.mozilla/firefox folder allows me to open nightly with my previous profile (without having to use -profile or similar of course).

Hopefully that clarifies the setup, and the issue?

Comment 12

[Jens Stutte [:jstutte]]

(In reply to Thinker Li [:sinker] from comment #8)

Just found that you can pass the argument --profile to specify a profile dir for tests.
The default behavior of mozregression will create a new temp profile every time. Why do you still get a lot file created in ~/.mozilla/firefox?

Would this qualify as a workaround in the sense of our S2 definition "...and a satisfactory workaround does not exist" and we can drop the severity here ? I get that it is confusing and hard to detect when someone encounters it.

Comment 13

[Thinker Li [:sinker]]

It is S3 now.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

(In reply to Jens Stutte [:jstutte] from comment #12)

(In reply to Thinker Li [:sinker] from comment #8)

Just found that you can pass the argument --profile to specify a profile dir for tests.
The default behavior of mozregression will create a new temp profile every time. Why do you still get a lot file created in ~/.mozilla/firefox?

Would this qualify as a workaround in the sense of our S2 definition "...and a satisfactory workaround does not exist" and we can drop the severity here ? I get that it is confusing and hard to detect when someone encounters it.

FWIW that is not a workaround, because mozregression (or an older build) will still create a ~/.mozilla/firefox for crash reports and telemetry and so on, which causes the issue regardless.

That said, the "workaround" is wiping that directory afterwards...

Comment 15

[Thinker Li [:sinker]]

I have one patch for firefox to check profiles.ini for legacy dir so it would not wrongly use the directory created for running mozregression. profiles.ini exists only if a real legacy profile has been created.
Another patch for mozregression clean up the directory before existing if the directory was there when the test started.
I will submit at least one of them next week.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 259356

Comment 17

[Thinker Li [:sinker]]

Attachment: Bug 2003137 - Check profiles.ini of legacy dir.

Check the existence of legacy dir not only against the directory but
also "profiles.ini" in it.

Prevent Firefox from ignoring XDG profiles when legacy directory is
accidentally created. Even when using XDG base directory for profiles,
Firefox can sometimes accidentally create the legacy profile directory
(~/.mozilla/firefox) (e.g., via mozregression or crash reports). When
this happens, Firefox mistakenly defaults to using the legacy
directory, ignoring valid XDG profiles, even if the legacy directory
is empty. This change checks for the existence of "profiles.ini"
within the legacy directory. If the file is missing, the legacy
directory is considered empty and is skipped, ensuring the application
correctly uses profiles from the XDG directory.

Comment 18

[Thinker Li [:sinker]]

Attachment: Bug 2003137 - Add XDG test for legacy directory without profiles.ini

Add a new marionette test to verify that when the legacy Firefox directory
(~/.mozilla/firefox) exists but profiles.ini does not, Firefox correctly
falls back to XDG Base Directory specification and creates profiles in
~/.config/mozilla/firefox instead.

The test verifies:

• Profile is created in XDG location (.config/mozilla/firefox)
• profiles.ini is created in XDG directory, not legacy directory

This covers the edge case where the legacy directory exists but was never
properly initialized (e.g., manually created, incomplete installation, or
profiles.ini was deleted).

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Hi Thinker, do we have a reviewer lined up for these patches?

Comment 20

[Donal Meehan [:dmeehan]]

To add to comment 19
The patches are now reviewed, but are not landed yet.
This is the final week of beta for Fx147, with only one beta build left in the cycle.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e8a2667bdcf4
https://hg.mozilla.org/integration/autoland/rev/08c7f49f9ab2
Check profiles.ini of legacy dir. r=gerard-majax
https://github.com/mozilla-firefox/firefox/commit/1635d321d553
https://hg.mozilla.org/integration/autoland/rev/1a0673497d59
Add XDG test for legacy directory without profiles.ini r=gerard-majax

Comment 22

[Thinker Li [:sinker]]

Just landed the code.

Comment 23

[Donal Meehan [:dmeehan]]

Feel free to add a beta uplift request when you are ready.
If it's low risk, we can take it before 147.0b9 builds and it will have a couple of days in nightly before that.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/490dda6c6541
https://hg.mozilla.org/integration/autoland/rev/b753b15b9661
Revert "Bug 2003137 - Add XDG test for legacy directory without profiles.ini r=gerard-majax" for causing nsXREDirProvider::EnsureDirectoryExists related xpcshell crashes.

Comment 25

[Serban Stanca [:SerbanS]]

Reverted this because it was causing nsXREDirProvider::EnsureDirectoryExists related xpcshell crashes.

• Revert link
• Push with failures
• Failure Log
• Failure line: PROCESS-CRASH | 3ada05b6-ddd8-81c5-b412-420bb3ded71c | application crashed [@ nsXREDirProvider::EnsureDirectoryExists] | browser/components/backup/tests/xpcshell/test_BackupService_archive.js

Comment 26

[Donal Meehan [:dmeehan]]

:sinker, Fx147 merges to release on Monday 2026-01-05.
147.0 RC1 builds on Monday.
There is little time to get this fix into Fx147

Comment 27

[Thinker Li [:sinker]]

I am fixing test cases that pass with existing bugs of nsXREDirProvider. I mean if these bugs are fixed (this bug is going to), the tests will fail.

Comment 28

[Thinker Li [:sinker]]

Attachment: Bug 2003137 - Create an empty profiles.ini in the legacy directory for TestXREAppDir.cpp.

A legacy directory is valid/or existing only if profiles.ini is there.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

It's too late for this to land in 147 at this point and is also getting close to the same for 148. Are there any updates on this landing soon?

Comment 30

[Thinker Li [:sinker]]

I have two more patches reviewing.

Comment 31

[Donal Meehan [:dmeehan]]

:sinker, next week is the last week of beta for Fx148.
Do you still plan on having something safe to uplift in time, or will this need to wait until Fx149?

Comment 32

[Thinker Li [:sinker]]

I am waiting for one more patch to be review. fx149 is where it should go.