1948976 - desktop.ini will be created in %UserProfile%\Documents\desktop.ini

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P3)

Description

[Fireleaf]

Steps to reproduce:

Just start Firefox version 134.x or greater (135.0). My Firefox starts on newtab page but the url does not matter. No interaction is needed. A not specifiable time later firefox.exe accesses the %userprofile%\documents folder.

Actual results:

Firefox.exe tries to read the desktop.ini in the documents folders of the current userprofile.
That is not really a problem, but when the file does not exits, firefox creates the file.
The content is similar with the one from the windows operating system. But that firefox creates the file without the user knowing is not an acceptable behavior.

Expected results:

Firefox should not create files in folders were he has no business with.
Even accessing the folder without good reason is questionable.
The creation of the desktop.ini would be in most cases not be a great deal to the user, but in our company we use folder redirects and we don‘t want any of the desktop.ini files in our profile shares. And we don‘t want to resort to blocking access or scripting something to fix this „problem“.

Comment 1

[Francesco Lodolo [:flod]]

I might be wrong, but Storage Quota seems to be the only thing looking for desktop.ini
https://searchfox.org/mozilla-central/search?q=desktop.ini

Comment 2

[Fireleaf]

https://searchfox.org/mozilla-central/search?q=%25USERPROFILE%25\\Documents
https://searchfox.org/mozilla-central/search?q=CSIDL_PERSONAL
https://searchfox.org/mozilla-central/search?q=SHGetSetFolderCustomSettings
https://searchfox.org/mozilla-central/search?q=SHFOLDERCUSTOMSETTINGS
https://searchfox.org/mozilla-central/search?q=FOLDERFLAGS

Comment 3

[Fireleaf]

https://connect.mozilla.org/t5/discussions/firefox-134-0-blocked-by-defender-needs-controlled-folder-access/td-p/83181
https://www.reddit.com/r/firefox/comments/1hwvtp2/why_the_new_ff_134_wants_to_see_my_personal/
and it spreads
https://www.reddit.com/r/LibreWolf/comments/1hz3ch4/why_does_librewolf_try_to_access/

Comment 4

[probica]

This is a big issue for me, the only other time any program creates desktop.ini in My documents is after cumulative Windows update and that is ok, this is not. No other program is doing this, never before FF created anything in My Documents until version 134 (tested and it is still present in FF 136b9). It creates false alerts with my security software, also I have My Documents redirected to other disk and I want it completely empty since I have enabled display hidden files and desktop.ini is always visible if present. I know purpose of this file but it is not mandatory and in my case I prefer it not present...so can you please stop process that is creating it from version 134. Tested with 133.0.3 version it is not created, update to 134 -> created at random intervals, having pop-up alerts "...Firefox is trying to write to My Documents". I can't update to anything past 133 version because of this.

Comment 5

[Jens Stutte [:jstutte]]

As far as I can tell the use inside quota manager is only for checks if something IsOSMetadata (and that is there for a long time). Am I overlooking something, Jan?

I can't update to anything past 133 version because of this.

From the release notes for 134 nothing really stands out to me.

Comment 6

[Jan Varga [:janv]]

That's correct. Quota Manager only checks if an unexpected file found during directory scanning is a known OS metadata file. It never creates or reads from desktop.ini.

Comment 7

[Jens Stutte [:jstutte]]

Let's move this closer to Windows folks then.

Comment 8

[Ray Kraesig [:rkraesig]]

Ordinarily I would ask for confirmation via ProcMon that it's Firefox that's actually creating the file, but it seems someone on Reddit has already successfully done that.

The only thing I can think of in Firefox that might create that file is the Windows file-selection dialog, which (as designed by Microsoft) has an embedded Explorer view. That should only happen if and when you actually visit %USERPROFILE% in that dialog, though, and it's also not anything new.

@Fireleaf: Could you go to about:third-party and check to see if there any interesting DLLs being loaded into the Firefox process?

Comment 9

[Ray Kraesig [:rkraesig]]

Addendum:

• Does this also happen in Troubleshoot Mode? In a fresh profile?
• Since all reports indicate this happened sometime between v133 and v134, can you try running mozregression to see if it can more precisely pinpoint the change that's causing this?

Comment 10

[Fireleaf]

@Ray
The File is created by Firefox.exe, confimed via ProcMon.
13:43:59,2110007 firefox.exe 13964 CreateFile C:\Users\XXX\Documents\desktop.ini SUCCESS Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: HS, ShareMode: Read, Delete, AllocationSize: 0, OpenResult: Created 13:43:59,2111438 firefox.exe 13964 **WriteFile** C:\Users\XXX\Documents\desktop.ini SUCCESS Offset: 0, Length: 2, Priority: Normal 13:43:59,2112144 firefox.exe 13964 CloseFile C:\Users\XXX\Documents\desktop.ini SUCCESS

The file is created after opening a new firefox window and without any user interaction or open-/savefiledialog. In the first 10-30 seconds.
about:third-party is empty.
{ "modules": [], "blocked": [] }

The problem does happen on a fresh windows 10 install, with a fresh install of firefox, therefore a fresh profile.
It also happens in Troubleshoot mode.
The mozregression is a bit tedious, because you always have to wait the random time. To be safe i would wait 1 better 2minutes.
I hope i get later a bit time to do that for you.

But first, if it helps, i pinpointed the exact line of code that creates the desktop.ini.
No quotamanager i think.
I'm now on the 136.0 release version. I used the external/remote debugging.

resource:///modules/backup/BackupService.sys.mjs
In the function initBackupScheduler() beginning on line 3157.
The desktop.ini is created after setting the eventhandler at line 3192.
this.#observer = (subject, topic, data) => { ** this.onObserve(subject, topic, data);** };
subject: XPCWrappedNative_NoHelper
topic: "idle"
data: "15"

Sorry, i'm not a programmer. That is all the help i can get you.
Good luck

Comment 11

[Fireleaf]

Addendum:
It has to be the only firefox window. When you open a second one the line is executed but no desktop.ini is created.
data: "16" is sometimes 16. But i better stop, because i don't really know what is going on or interpret the source code.
All to do for me is to say thanks in advance.

Comment 12

[Jens Stutte [:jstutte]]

(In reply to Fireleaf from comment #10)

resource:///modules/backup/BackupService.sys.mjs
In the function initBackupScheduler() beginning on line 3157.
The desktop.ini is created after setting the eventhandler at line 3192.
this.#observer = (subject, topic, data) => { ** this.onObserve(subject, topic, data);** };
subject: XPCWrappedNative_NoHelper
topic: "idle"
data: "15"

That line would point to bug 1901526, any ideas, Mike?

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Interesting. So, the BackupService is not intentionally creating any files here in the Documents folder, but it is attempting to ask the OS for the path to the Documents folder here: https://searchfox.org/mozilla-central/rev/9c395b6371eaea0d15f9c8a37889022be350cf0b/browser/components/backup/BackupService.sys.mjs#108

as that was ultimately the planned default destination for profile backups.

It appears that merely gaining the path to the Documents folder via Services.dirsvc.get("Docs", Ci.nsIFile).path is enough to create the desktop.ini folder in the Documents directory if it doesn't already exist. So I think this is a byproduct of the backup service initializing, but the ultimate responsibility of the nsIDirectoryService, which is getting us the path.

Adding support for getting the Documents directory path was done here: https://bugzilla.mozilla.org/show_bug.cgi?id=1890352.

rkraesig - do we know why this routine would ultimately cause a desktop.ini file to be created in the Documents folder?: https://searchfox.org/mozilla-central/rev/9c395b6371eaea0d15f9c8a37889022be350cf0b/xpcom/io/SpecialSystemDirectory.cpp#683-684

Comment 14

[Ray Kraesig [:rkraesig]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #13)

rkraesig - do we know why this routine would ultimately cause a desktop.ini file to be created in the Documents folder?: https://searchfox.org/mozilla-central/rev/9c395b6371eaea0d15f9c8a37889022be350cf0b/xpcom/io/SpecialSystemDirectory.cpp#683-684

The function in question invokes ::SHLoadLibraryFromKnownFolder(), IShellLibrary::GetDefaultSaveFolder(), and IShellItem::GetDisplayName(). These import some Explorer code, which can and occasionally does do arbitrary "helpful" things; the culprit is probably the first or second of them.

I think this could all be simplified down to a call to SHGetKnownFolderPath(); that may have the same problem, but I suspect as long as you don't pass KF_FLAG_INIT it won't. Alternatively, we could try to adapt the mechanism used by ShellExecuteByExplorer to offload the relevant COM objects into explorer.exe.

Alternatively again, we could use some other path for profile backups; it's not obvious to me that "Documents" is the right location. EDIT: Or just compute this only lazily -- it's not being used yet, is it?

Comment 15

[Mike Conley (:mconley) (:⚙️)]

it's not obvious to me that "Documents" is the right location.

I think ultimately that's a PM call, but I will say that it was originally chosen explicitly by PM (drubino), and not arbitrarily.

Or just compute this only lazily -- it's not being used yet, is it?

It is not, no - just to collect some basic telemetry after startup by default. If there's an opportunity to get this path lazily, I'm all for it. What did you have in mind?

Comment 16

[Ray Kraesig [:rkraesig]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #15)

I think ultimately that's a PM call, but I will say that it was originally chosen explicitly by PM (drubino), and not arbitrarily.

:+1:

It is not, no - just to collect some basic telemetry after startup by default. If there's an opportunity to get this path lazily, I'm all for it. What did you have in mind?

... basically what's already happening in BackupService.sys.mjs, so never mind that.

(And even if the use in telemetry were removed, it would also just be kicking the can down the road, if backups are ever expected to happen by default and in the background. Not exactly my most well-thought-out idea, that.)

Comment 17

[Masatoshi Kimura [:emk]]

(In reply to Ray Kraesig [:rkraesig] from comment #14)

I think this could all be simplified down to a call to SHGetKnownFolderPath(); that may have the same problem, but I suspect as long as you don't pass KF_FLAG_INIT it won't.

Please make sure bug 837932 does not regress.

Comment 18

[probica]

For my own reasons I have My Documents redirected to portable drive, tried never versions again, just to check, when I start FF 134+ versions I'm faced with error pop-ups if I remove portable drive and start Firefox, since it attempt to write to non existent directory! No other program does that, even Edge does not try to create files in My Document without permission, this is not some minor bug just because it not obvious at first, this is serious problem - Firefox 134+ started to use some functions in very improper way since this kind of behavior is only seen with ransomware/viruses and this should be fixed ASAP with higher priority, please.

Comment 19

[Rares Doghi, Desktop QA]

I was able to reproduce this issue in our latest Release 138, Beta 139 as well as our latest Nightly build 140.0a1 (2025-05-14). The file is not created with esr128.10

Comment 20

[grundtworks]

Please be advised that in addition to the original reporter's use case, this is also a problem for Windows users that have enabled the optional Controlled Folder Access ransomware feature in Windows.

The behavior with Controlled Folder Access enabled is that when Firefox attempts to write to the Documents folder it is blocked, and a notification is displayed to the user. The user can, if they choose, click a link in the notification to "allow an app through Controlled folder access". If they do so, future writes will be allowed. However, if they take no action (i.e. elect not to make an exception for Firefox), Firefox will continue to be blocked and they will get this notification every time Firefox (routinely) makes the attempt.

I'm aware of 2 discussions that have been opened regarding this behavior:
2025-01-11 Firefox 134.0 blocked by Defender, needs Controlled Folder Access!
2025-05-26 Does firefox ever write to logged in users Documents folder?

In Windows 10, the steps to enable the Controlled Folder Access feature are:

1. right-click Start Menu
2. Settings
3. Update & Security
4. Windows Security (left-side menu)
5. Virus & threat protection
6. Manage ransomware protection
7. Controlled folder access (toggle)

Comment 21

[Ed]

In Windows 11, the steps to enable the Controlled Folder Access feature are:

• Right-click Start Menu > Settings > Privacy & Security on left side
• Windows Security (top of right side menu)
• Virus & threat protection > Ransomware protection > Manage ransomware protection
• Controlled folder access (toggle)

Comment 22

[Johnathan]

I note I receive these alerts even though desktop.ini already exists in the default users Documents folder so it's not just trying to place a desktop.ini when one is lacking it's trying to modify/replace an existing one too assuming it's trying to do anything with desktop.ini in the first place! In the mean time I have disabled the about:config browser.backup.enabled option as it's been reported doing so stops the bug from rearing its ugly head. And note that the proper place to locate the users Document folder is to query the registry string HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal and not assume it's at the value it normally defaults to. Not that any browser these days should be looking to have write access to protected user personal files. It looks like this browser.backup function is not complete anyway since it cannot write to its default location and no GUI interface exists beyond an undocumented about:config browser.backup.location string to locate the backups in a sensible and secure location. IMHO browser proflie backups should be located in a backup subfolder in the existing profiles root folder and not put in an arbitrary completely unrelated users document subfolder where not program data or executables belong.

Comment 23

[Johnathan]

(In reply to Johnathan from comment #22)

I note I receive these alerts even though desktop.ini already exists in the default users Documents folder so it's not just trying to place a desktop.ini when one is lacking it's trying to modify/replace an existing one too assuming it's trying to do anything with desktop.ini in the first place! In the mean time I have disabled the about:config browser.backup.enabled option as it's been reported doing so stops the bug from rearing its ugly head. And note that the proper place to locate the users Document folder is to query the registry string HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal and not assume it's at the value it normally defaults to. Not that any browser these days should be looking to have write access to protected user personal files. It looks like this browser.backup function is not complete anyway since it cannot write to its default location and no GUI interface exists beyond an undocumented about:config browser.backup.location string to locate the backups in a sensible and secure location. IMHO browser proflie backups should be located in a backup subfolder in the existing profiles root folder and not put in an arbitrary completely unrelated users document subfolder where no program data or executables belong.

Comment 24

[Nick Rishel [:nrishel]]

Attachment: Bug 1948976 - Retrieve the Windows Documents folder via `SHGetKnownFolderPath` to avoid generating desktop.ini files, and retrieve it directly instead of routing through the Documents virtual folder. r=emk,#win-reviewers

Also removes fallback to GetWindowsFolder. The implementation thereof is based on SHGetSpecialFolderPath, which was depreciated in favor of SHGetFolderPath, which is a wrapper for SHGetKnownFolderPath for versions of Windows supported. CSIDL_MYDOCUMENTS is documented as equivalent to FOLDERID_Documents.

Comment 25

[grundtworks]

(In reply to Nick Rishel [:nrishel] from comment #24)

I would like to just mention again that the Documents folder in Windows is one that is "protected by default" by the "Controlled Folder Access" feature.

So, while this proposed bug fix takes care of the reporter's particular issue (concerning creation of an .ini file), it does not address the issue that others are having, who have the "Controlled Folder Access" feature enabled. (see my prior comment #20 for further details).

The Documents folder shouldn't be used as a default destination to write files to (except in instances where it's used as the default for a "Folder Chooser" dialog, since the user would then be explicitly choosing to place files there).

Comment 26

[Nick Rishel [:nrishel]]

Solving the initially reported issue is the scope of this bug, but we could definitely use a new bug for the CFA issue. If you write that up, it would be helpful to add this bug in the "See Also" section.

Comment 27

[grundtworks]

(In reply to Nick Rishel [:nrishel] from comment #26)

I'm electing not to write up a separate bug at this time because I'm unable to reproduce that issue (frequent Controlled Folder Access notifications regarding Firefox attempting to write to the Documents folder).

Months ago, when I was experiencing the issue, I discovered a setting (browser.backup.enabled) that could be set to "false" to prevent the issue.
When I saw your comment advising that I open a separate bug, I reverted that setting to its default (true), but several days have elapsed and I have still not seen the issue.

I suspect it may be because the BackupService (which was the source of the issue) is a preview feature.
Since last encountering the issue, I've created a new Profile, so perhaps that explains why I'm no longer affected.

If I do encounter the issue again, I'll open a bug.

Meanwhile, perhaps you'd consider including a comment in your bug fix, warning of the potential consequences of using the Windows Documents folder as a default file destination ?

Comment 28

[grundtworks]

Meant to include this link in comment #27:
BackupService

Comment 29

[Nick Rishel [:nrishel]]

Keeping the bug fix as is for but will keep this issue at top of mind.

That said I don't believe we ever directly wrote to the Documents folder without user interaction, so this might have been fixed Windows-side by making an exception for desktop.ini files implicitly created by older shell APIs.

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4429d47b712a
https://hg.mozilla.org/integration/autoland/rev/e2ccd5651da9
Retrieve the Windows Documents folder via `SHGetKnownFolderPath` to avoid generating desktop.ini files, and retrieve it directly instead of routing through the Documents virtual folder. r=emk

Comment 31

[grundtworks]

(In reply to Nick Rishel [:nrishel] from comment #29)

... I don't believe we ever directly wrote to the Documents folder without user interaction ...

See: BackupService.sys.mjs (line 699, line 108)

Comment 32

[Iulian Moraru]

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

Comment 33

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 34

[Rares Doghi, Desktop QA]

This issue is verified as fixed in our latest Nightly 142.0a1 (2025-07-01). I can no longer see the desktop.ini file being created.

Comment 35

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

The patch landed in nightly and beta is affected.
:nrishel, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox141 to wontfix.

For more information, please visit BugBot documentation.

Comment 36

[Rares Doghi, Desktop QA]

Updating the main status flag.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Should we backport this to ESR140? It cherry-picks cleanly.

Comment 38

[Nick Rishel [:nrishel]]

It should be reasonably safe to backport but it's also a fairly niche issue. I suppose it's worth uplifting if only to avoid decision paralysis.

If we're going to uplift this we should consider Bug 1974356 too since it resulted in measurable change in IO in CI.

Comment 39

[Nick Rishel [:nrishel]]

Attachment: Bug 1948976 - Retrieve the Windows Documents folder via `SHGetKnownFolderPath` to avoid generating desktop.ini files, and retrieve it directly instead of routing through the Documents virtual folder. r=emk,#win-reviewers

Also removes fallback to GetWindowsFolder. The implementation thereof is based on SHGetSpecialFolderPath, which was depreciated in favor of SHGetFolderPath, which is a wrapper for SHGetKnownFolderPath for versions of Windows supported. CSIDL_MYDOCUMENTS is documented as equivalent to FOLDERID_Documents.

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

Comment 40

[Nick Rishel [:nrishel]]

Attachment: Bug 1948976 - Retrieve the Windows Documents folder via `SHGetKnownFolderPath` to avoid generating desktop.ini files, and retrieve it directly instead of routing through the Documents virtual folder. r=emk,#win-reviewers

Also removes fallback to GetWindowsFolder. The implementation thereof is based on SHGetSpecialFolderPath, which was depreciated in favor of SHGetFolderPath, which is a wrapper for SHGetKnownFolderPath for versions of Windows supported. CSIDL_MYDOCUMENTS is documented as equivalent to FOLDERID_Documents.

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

Comment 41

[Nick Rishel [:nrishel]]

Attachment: Bug 1948976 - Retrieve the Windows Documents folder via `SHGetKnownFolderPath` to avoid generating desktop.ini files, and retrieve it directly instead of routing through the Documents virtual folder. r=emk,#win-reviewers

Also removes fallback to GetWindowsFolder. The implementation thereof is based on SHGetSpecialFolderPath, which was depreciated in favor of SHGetFolderPath, which is a wrapper for SHGetKnownFolderPath for versions of Windows supported. CSIDL_MYDOCUMENTS is documented as equivalent to FOLDERID_Documents.

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

Comment 42

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Unnecessary desktop.ini creation in Windows Documents folder when queried by directory service.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: n/a
• Risk associated with taking this patch: Low
• Explanation of risk level: Trivial to verify code, rarely used in code..
• String changes made/needed: n/a
• Is Android affected?: no

Comment 43

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/3df3879e70f5

Comment 44

[Rares Doghi, Desktop QA]

This issue is verified as fixed in our latest ESR builds 140.2.0esr.