Affected versions

• 93.0b4MSIX
• 94.0a1MSIX
• 92.0b9MSIX

Affected platforms

• Windows 11 - winver Build 22454.100 (Dev Channel) / Build 22454.rs_prerelease.210903-1516

Preconditions

• Have normal Firefox.exe installed

Steps to reproduce

1. Instal Firefox .msix package and open it (we use treehereder builds).
2. Close it and open it again.
   3.1. Open Web Console - Ctrl + Shift + K.
   3.2. Sign in to Sync.
   3.3. Observe about:addons -> Languages

Expected result

• 3.1. The console is displayed as expected.
• 3.2. User can sign in to Sync.
• 3.3. All language add-ons are enabled.

Actual result

• 3.1. Blank console displayed.
• 3.2. Cookies and local storage are required error is displayed: link.
• 3.3. All language addons are disabled. If they are enabled manually and firefox closed and reopened they need to be re-enabled again-> screenrecording

Regression range

• I don’t think this is a Firefox regression. This happens with the latest MS Windows update (Build 22454.100) only. On Version 21H2 (OS Build 22000.184) the issues were not reproducible.

Notes

• Attached browser console errors.
• MSIX builds were downloaded from treeherder.
• 92.0b9 was installed using ms-windows-store://pdp/?productid=9P9GJR8PH8TT link. I can reproduce the above problems as well besides language one. On this build, there are no Language addons installed.
• about:support page is blank as well
• saved logins are not remebered after reopening Firefox
• S2 because this only happens if a normal Firefox is installed before the .msix installation.

I've marked this confidential since we don't want the ms-windows-store://pdp/?productid=9P9GJR8PH8TT URL to become public. The private audience will deny access but the link shows what we are doing, which is not quite public yet.

As best I can tell, this is what's happening:

When the Mozilla directory exists in %AppData% or %LocalAppData%, a new profile will be created there, on the host filesystem, instead of in the package's "private per-user, per-app location" (%LocalAppData%\Packages\Mozilla.Firefox.Beta_gmpnhwe7bv608\LocalCache etc). Contrary to what Microsoft's documentation says, this is the case in the latest Windows 10 (tested just now on 19043.1202) and on all the win11 I tested (22000.184 on Beta, 22454.1000 on Dev channel). So the issue here isn't migrating a profile, I think it's just that there are any root directories at all.

When a file under %AppData% (maybe also %LocalAppData%) is moved with MoveFileExW, it will locate the existing file outside of the package's private location, but it will first try to open the directory to move it in the private location. That directory likely doesn't exist, so this fails. On 22000.184, there is then a fallback (within the system call) to use the real existing directory, but for some reason on 22454.1000 this doesn't happen. I clearly saw this happening (and not happening) in Process Monitor, it's the reason for the "Could not move temporary file" errors. It's possible that this affects other operations as well, and there may be other issues, but this is the clearest.

This seems to be pretty clearly a bug, but I don't see it listed in the release notes for 22454 or 22458. I'm going to update to 22458 and see if it's fixed, if not I'll look into reporting it to Microsoft.

I've confirmed that this issue is present in 22458 (latest dev channel) but not 22000.194 (latest beta channel). This does not appear to affect moving files within the AppData\Local\Temp directory, which I had thought would be a good example.

A clarification:

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #2)

When the Mozilla directory exists in %AppData% or %LocalAppData%, a new profile will be created there, on the host filesystem, instead of in the package's "private per-user, per-app location" (%LocalAppData%\Packages\Mozilla.Firefox.Beta_gmpnhwe7bv608\LocalCache etc). Contrary to what Microsoft's documentation says ...

I think I understand what the documentation says better now. There's a section that explains what happens with a write under AppData:

Windows 10, version 1903 and later: New files and folders created under the following directories are redirected to a per-user, per-package private location:

• Local
• Local\Microsoft
• Roaming
• Roaming\Microsoft
• Roaming\Microsoft\Windows\Start Menu\Programs

This strongly suggests that the private location is used when files or folders are created directly under these directories (otherwise "Local" would cover "Local\Microsoft"). So when unpackaged Firefox had never run before and there was therefore no {Local,Roaming}\Mozilla in the real AppData, when we create those directories for the first time they will land in the private location, and subsequent files created under those stay in the private location because the private location is always checked first when creating/opening files. But when the top level directory already existed in the real AppData, files and subdirectories will be created on the real AppData.

I haven't tested it, but this gets more confusing if the same directory exists in both places, say the packaged Firefox creates its private directories, then unpackaged Firefox runs and creates directories in the real AppData. There is supposed to be a merge at runtime, preferring files from the private location:

In response to a file open command, the OS will open the file from the per-user, per-package location first. If this location doesn't exist, the OS will attempt to open the file from the real AppData location. If the file is opened from the real AppData location, no virtualization for that file occurs. File deletes under AppData are allowed if user has permissions.

This might lead to the packaged Firefox being able to read Mozilla\Firefox\postSigningData, though this seems like a fairly low-risk edge case. I don't like how many scenarios I'm having to think through, even if they become exponentially less likely.

This is still occurring in the latest Dev build (22468). I haven't gotten a response from Microsoft, other than to tell me to file a Feedback Hub bug (this doesn't seem to be publicly accessible).

Still occurring on 22471.

To reproduce with the attached package:

1. Install the self-signed key.cer to the local machine's trusted root store. (Be sure to only do this in a VM or remove it immediately after testing.)
2. Create a directory %localappdata%\renametest
3. Install the renamer.msix package, allowing it to immediately launch.

This will attempt to create renametest\1.txt and rename it to renametest\2.txt, which fails on Windows 11 Dev channel build 22478, and back at least to 22454. After launching, there will be a "failed renaming" error message box with code 2 (file doesn't exist). renametest\1.txt should exist after running the test.

On RTM and Beta Windows 11, the file will be successfully renamed to renametest\2.txt.

The attached .zip also includes Process Monitor traces and the source for the test package.

Happens for me on 22478.1012 rs_prerelease (Windows Insider Dev Channel)

Here are WinDbg Preview Time Travel Debugging traces of success on 22000.194 and failure on 22483, in case someone knowledgeable with Windows internals cares to take a look.

Do we intend to share profiles between MSIX packaged Firefox and unpackaged Firefox? If not, MSIX packaged Firefox should create %localappdata%\Mozilla first to prevent it from polluting the real %localappdata%\Mozilla directory.

That's an interesting idea, but I couldn't get it to work. I tried using CreateDirectoryW to create %localappdata%\renametest before creating the file, but if the real directory existed first then the package doesn't create the directory in the package location, and still creates the file in the real location (testing on 22483). Could you post your code?

We're not trying to put the package's profiles in the real dirs, but I didn't know there was a way to avoid it as long as the real %localappdata%\Mozilla existed first. Maybe it would work if we explicitly created the directory using the full path to the package location? The most straightforward solution would be to use a unique name instead of Mozilla for the package, but that might be a fairly invasive change.

(In reply to Masatoshi Kimura [:emk] from comment #10)

if the renamer app creates %localappdata%\renametest

This was not an exact step I did. I created a folder with a temporary name under %localappdata%, then I renamed it to renametest.

(In reply to Masatoshi Kimura [:emk] from comment #13)

This was not an exact step I did. I created a folder with a temporary name under %localappdata%, then I renamed it to renametest.

Good idea! Renaming the package's Local\<temp> deals directly with the package's own Local, so we always end up with a Local\renametest for the package. Worked for me on 22000.194 and 22483. The rename should fail if the package already had a Local\renametest, then we'd just need to clean up the temp.

Since we decided to stop migrating profiles (bug 1736876) we don't need access to the non-package filesystem anymore, so we could do this early on to avoid any interaction between non-packaged and packaged profile systems, I think...

If we do this, will packaged Firefox ever see the non-packaged profiles.ini/installs.ini? Will it be able to access non-packaged profiles? Concretely: If there are profiles created specific to the package but stored in the non-package location (as would happen currently, if the non-package Mozilla existed), would those become inaccessible if we later implement this method to ensure the package has its own Mozilla? If they are still accessible, I expect they would still have the issues described in this bug on Win 11 Dev. If not accessible, then we want to make this change as soon as possible, if we make it at all, to avoid completely losing profiles of early MSIX users.

ni? Nick to bring this possibility to your attention.

Because we've explicitly turned off profile migration for MSIX builds (https://bugzilla.mozilla.org/show_bug.cgi?id=1736876) I think we can lower the severity of this.

I do think it should block re-enabling that, though. For that reason I'm blocking 17340000 on this.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #15)

Because we've explicitly turned off profile migration for MSIX builds (https://bugzilla.mozilla.org/show_bug.cgi?id=1736876) I think we can lower the severity of this.

I do think it should block re-enabling that, though. For that reason I'm blocking 17340000 on this.

But is this really about migration? This also affects my existing MSIX installation for stable channel, so I think this should be considered as severe enough.

Edit: Anyway, I moved my profiles to %LOCALAPPDATA%/Packages/.../LocalCache/{Local,Roaming}/Mozilla/Firefox/Profiles and then there's no problem anymore, except the profile button on about:supports is now broken.

(In reply to Kagami :saschanaz from comment #16)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #15)

Because we've explicitly turned off profile migration for MSIX builds (https://bugzilla.mozilla.org/show_bug.cgi?id=1736876) I think we can lower the severity of this.

I do think it should block re-enabling that, though. For that reason I'm blocking 17340000 on this.

But is this really about migration? This also affects my existing MSIX installation for stable channel, so I think this should be considered as severe enough.

Ping for this. :-)

I'm so sorry I missed this comment - my bad.

(In reply to Kagami :saschanaz from comment #16)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #15)

Because we've explicitly turned off profile migration for MSIX builds (https://bugzilla.mozilla.org/show_bug.cgi?id=1736876) I think we can lower the severity of this.

I do think it should block re-enabling that, though. For that reason I'm blocking 17340000 on this.

But is this really about migration? This also affects my existing MSIX installation for stable channel, so I think this should be considered as severe enough.

You're right, I misread before - this is indeed not related to migration. Given that I agree it may be higher priority.

It looks like ~2% of new MSIX installs since January happen on systems with a non-MSIX install - so they're all at risk of this (I would expect that if all of those people hit the issue we'd have at least one other bug about this - so it seems like a small fraction of those actually have issues).

I'm going to up the severity and reset the priority for now so we can re-triage this soon.

We talked about this issue a bit in a recent meeting. One idea that came up there (and also independently in https://bugzilla.mozilla.org/show_bug.cgi?id=1760396) is requesting the unvirtualizedResources capability in our MSIX package -- which would allow the MSIX version of Firefox to have unfettered access to the existing AppData directories (subject to regular Windows permissions, of course). This would allow us to not only fix this issue, but in theory we could also fix up any existing profiles in this state. It's also a simpler path forward here, and would reduce the differences between regular Firefox and MSIX Firefox, which would hopefully prevent similar issues in the future.

This capability requires Microsoft to approve our usage of it, but they have granted it to some non-Microsoft packages in the past - so there's some hope it may be possible.

Clearing NI as our current thoughts on unvirtualizedResources obviates the issue in question.

:bhearsum given that profile migration has been removed(?) and we've dropped the idea in favor of an alternative solution, think it's time to close this bug?

Dropping severity given aforementioned removal of profile migration.

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

:bhearsum given that profile migration has been removed(?) and we've dropped the idea in favor of an alternative solution, think it's time to close this bug?

I think we'd like to re-enable this at some point (https://bugzilla.mozilla.org/show_bug.cgi?id=1734000) - so we probably ought to keep this open. Lowering the severity makes a lot of sense though.

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:mpohle, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #25)

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:mpohle, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

see comment #24