2001887 - New XDG basedir support still creates an empty ~/.mozilla/extensions directory

Status: VERIFIED FIXED

(WebExtensions :: General, task, P2)

Description

[Emilio Cobos Álvarez [:emilio]]

STR:

• mv ~/.mozilla ~/.mozilla-bak
• Launch nightly

I expect a bunch of files to be under ~/.config/mozilla. That's alright and works. However the ~/.mozilla directory is resurrected and empty with a ~/.mozilla/extensions directory, which is rather weird / unexpected.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

I guess this is expected because of the aForceLegacy = true here: https://searchfox.org/firefox-main/rev/3f22e78e34249196edab0a5b756394169533b8a1/toolkit/xre/nsXREDirProvider.cpp#1177-1190?

Comment 2

[:gerard-majax]

This was a review requirement change, from rob I think?

Comment 4

[Mike Hommey [:glandium]]

Searching for addons in the legacy location is very much on purpose, but the problem here is the directory being created when it doesn't exist.

Comment 5

[Rob Wu [:robwu]]

(In reply to :gerard-majax from comment #2)

This was a review requirement change, from rob I think?

I was never involved in the thread, perhaps you were thinking of my feedback at bug 1986219? The original request in the current bug came from :glandium at https://phabricator.services.mozilla.com/D6995#inline-1400955

The directory is being created at https://searchfox.org/firefox-main/rev/af0f713f785417023666ef557e856b3a9d132041/toolkit/xre/nsXREDirProvider.cpp#1184,1187

I wonder how many still rely on this location. It is at https://searchfox.org/firefox-main/rev/af0f713f785417023666ef557e856b3a9d132041/toolkit/mozapps/extensions/internal/XPIProvider.sys.mjs#2571-2572 (along with the lookup of a registry key on Windows only), but by default we only look up in SCOPE_PROFILE: https://searchfox.org/firefox-main/rev/af0f713f785417023666ef557e856b3a9d132041/toolkit/mozapps/extensions/internal/AddonSettings.sys.mjs#125-138 (which is enabled by default on ESR only).

Comment 6

[:gerard-majax]

(In reply to Rob Wu [:robwu] from comment #5)

(In reply to :gerard-majax from comment #2)

This was a review requirement change, from rob I think?

I was never involved in the thread, perhaps you were thinking of my feedback at bug 1986219? The original request in the current bug came from :glandium at https://phabricator.services.mozilla.com/D6995#inline-1400955

Oops, maybe you're right

The directory is being created at https://searchfox.org/firefox-main/rev/af0f713f785417023666ef557e856b3a9d132041/toolkit/xre/nsXREDirProvider.cpp#1184,1187

Yes, thanks, and it confirms my memory of this being already created by default prior to my changes.
While it may look weird now that we support XDG_CONFIG_HOME, it predates it. I worry some of our code down the like in XPI/extensions handling may silently break if it does not exists for real

Comment 7

[Shmerl]

(In reply to :gerard-majax from comment #6)

Yes, thanks, and it confirms my memory of this being already created by default prior to my changes.
While it may look weird now that we support XDG_CONFIG_HOME, it predates it. I worry some of our code down the like in XPI/extensions handling may silently break if it does not exists for real

Would regression tests catch any issues if you just disable creating it when non in legacy mode?

Comment 8

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

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

For more information, please visit BugBot documentation.

Comment 9

[Shmerl]

Another issue that breaks XDG spec, just for the reference: bug #2005167.

Comment 10

[Rob Wu [:robwu]]

(In reply to :gerard-majax from comment #6)

(In reply to Rob Wu [:robwu] from comment #5)

The directory is being created at https://searchfox.org/firefox-main/rev/af0f713f785417023666ef557e856b3a9d132041/toolkit/xre/nsXREDirProvider.cpp#1184,1187

Yes, thanks, and it confirms my memory of this being already created by default prior to my changes.
While it may look weird now that we support XDG_CONFIG_HOME, it predates it. I worry some of our code down the like in XPI/extensions handling may silently break if it does not exists for real

The add-ons manager (extensions) don't care about the existence of the directory, see least comment 5 for an explanation on its non-use (other than ESR, or with a custom pref). All uses of this path can be found here:

• https://searchfox.org/firefox-main/search?q=XREUSysExt&redirect=false
• https://searchfox.org/firefox-main/search?q=XRE_USER_SYS_EXTENSION_DIR&redirect=false

Given the lack of use, I think that it would be okay to disable the directory creation.

:sinker
Please do not set severity (S3) on bugs, at least not for bugs in the WebExtensions product. Assigning severity is the responsibility of the triage owners (or their team). In the WebExtensions team, our query for bugs to triage exclude bugs that already have an assigned severity. So by changing the severity of a bug, you are increasing the likelihood of the bug to be unnoticed and therefore not get looked into.

Comment 11

[Thinker Li [:sinker]]

Sorry, I did these two bug by a mistake. Just fix it.

Comment 12

[Nika Layzell [:nika] (ni? for response)]

Seems like this is perhaps an extension issue, although the code exists within XPCOM. We can review the change from the extensions side, but I think it would just involve removing the EnsureDirectoryExists call (https://searchfox.org/firefox-main/rev/54da8f6bfead7871ca89f2cb18323af5f00d9620/toolkit/xre/nsXREDirProvider.cpp#1187) and doing some testing to ensure everything still works as expected.

Comment 13

[Rob Wu [:robwu]]

Attachment: Bug 2001887 - Stop creating ~/.mozilla/extensions directory

Comment 14

[Mike Kaply [:mkaply]]

Will this fix this?

https://bugzilla.mozilla.org/show_bug.cgi?id=732435

Comment 16

[Rob Wu [:robwu]]

(In reply to Mike Kaply [:mkaply] from comment #14)

Will this fix this?

https://bugzilla.mozilla.org/show_bug.cgi?id=732435

Yes. On Windows this code path uses Mozilla\Extensions\ instead of .mozilla/extensions/ - https://searchfox.org/firefox-main/rev/f9d8702e26624ab46a35bf6561a7c8143c6f246a/toolkit/xre/nsXREDirProvider.cpp#1262-1275

Bug 732435 points to %USERPROFILE%\Mozilla\, but according to this source at https://searchfox.org/firefox-main/rev/b67c6262ecbe7d4c9385a1bd335fd7dd1d3f887d/browser/components/enterprisepolicies/Policies.sys.mjs#467-468
the path is expected to be %USERNAME\AppData\Roaming\Mozilla. Is this as expected? Has nothing to do with this bug, but since we're looking at it, I'd like to double-check.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a46cfb4e6bad
https://hg.mozilla.org/integration/autoland/rev/b27778bb35e0
Stop creating ~/.mozilla/extensions directory r=mkaply

Comment 18

[Mike Kaply [:mkaply]]

Is this as expected? Has nothing to do with this bug, but since we're looking at it, I'd like to double-check.

Yes. Roaming is the default, so that's what %USERPROFILE%\Mozilla pointed to

Comment 19

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/b27778bb35e0

Comment 20

[Rob Wu [:robwu]]

Attachment: Bug 2001887 - Stop creating ~/.mozilla/extensions directory

Original Revision: https://phabricator.services.mozilla.com/D277627

Comment 21

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Firefox 147's release notes indicate support for the XDG Base Directory Specification.

If someone were to try this out, they would still see Firefox creating a ~/.mozilla/ directory, in violation of that spec. So the 147 release does not match user expectations in this regards. The directory creation was unnecessary, and this patch removes that.

• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: 1. On a new Linux user account (or at least one where ~/.mozilla/ was removed), start Firefox.

2. Verify that the ~/.mozilla/ directory was not created.

• Risk associated with taking this patch: low
• Explanation of risk level: Removes logic that creates the empty directory. Low risk because we do not rely on the directory's existence. The only build where users can opt in to the dependent feature is ESR, and even there users can create the directory themselves if needed.
• String changes made/needed: None
• Is Android affected?: no

Comment 22

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (149.0a1/20260114211245) and Beta (148.0b2/20260114090336) under Ubuntu 24.10 according to the STR from Comment 21.

Using a new Linux user account where the ~/.mozilla/ directoy is non-existent, installing and starting the browser will not create the ~/.mozilla/ directory, confirming the fix.

For comparison, I’ve also tested the latest Release (147.0/20260105210555) as well. Launching this browser version without the fix, will create the ~/.mozilla/ directory as expected.

When the uplift to Firefox Release is completed, I will check once again.

Comment 23

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/6bb55893a840
https://hg.mozilla.org/releases/mozilla-release/rev/eab1fbd3e5d6

Comment 24

[Alex Cornestean]

Verified as Fixed. Tested on the latest Release (147.0.1/2026011609130) under Ubuntu 24.10 according to the STR from Comment 21.

Using a new Linux user account where the ~/.mozilla/ directoy is non-existent, installing and starting the browser will not create the ~/.mozilla/ directory, confirming the fix.