Bug 1727878 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

# Setup: Normal Run

The profile directory gets sent to the directory provider/service [in `XRE_mainStartup()`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730). `nsXREDirProvider::SetProfile()` saves a reference to the profile root directory to return for "ProfD", but first it [resolves that path](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsXREDirProvider.cpp#233-239) (due to bug 1369670). A profile path comes out of the INI looking like:

```C:\Users\agash\AppData\Roaming\Mozilla\Profiles\usjl8hcn.default-beta```

If that's only a virtual path, and the profile is actually in a package's private location, this resolves to a final form like:

```C:\Users\agash\AppData\Local\Packages\Mozilla.Firefox.Beta_gmpnhwe7bv608\LocalCache\Roaming\Mozilla\Firefox\Profiles\usjl8hcn.default-beta```

This introduces a potential inconsistency between the profile service's list of profiles and the directory service's "ProfD" [1].

# Restart for Profile Reset

1. When shutting down for restart, "ProfD" is [saved](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#278) and used to [set `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#146-148).
2. On restart, `nsToolkitProfileService::SelectStartupProfile()` will try to get a profile [using `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1301).
3. `GetProfileByDir()` looks for a profile with an [equal root directory](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/toolkit/profile/nsToolkitProfileService.cpp#1884).
4. `Equals` does some canonicalization but [only up to short paths](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/io/nsLocalFileWin.cpp#2950-2959) on Windows, so the paths won't match, and no profile is passed out of `SelectStartupProfile()`.
5. Because we're trying to do a profile reset, [`SelectProfile()` fails](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2737-2740).
6. Firefox [exits](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4504-4507).

# Why is this not prevented by resetSupported?

`ResetProfile.resetSupported()` is supposed to detect that this would happen. It checks that the current profile is known to the profile manager, using [roughly the same logic](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/modules/ResetProfile.jsm#36-45). If not found it should hide the "Refresh Firefox..." button on about:support and elsewhere.

The problem is that `nsXREDirProvider::SetProfile()` is [called with `mProfD`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730), and when it resolves the path it modifies the `nsIFile` that was passed in. If we had selected a default profile, this is the same `nsIFile` that is used to store the profile's root dir in the profile service [2]. `SetProfile()` modifies the path when resolving it, so they'll always match in this case. This can be seen in about:profiles in a package: Only the root directory of the current profile is resolved, and it is still recognized as the current profile (showing "This is the profile in use and it cannot be deleted"), though see Mode B below.

# Failure Mode B

There's another failure mode, call it Mode B: After a non-profile-reset restart, e.g. "Restart normally..." in about:profiles, the profile list never gets a resolved root path for the active profile, though "ProfD" in the dirsvc is resolved, because these are different `nsIFile`s [3]. As a result the "Refresh Firefox..." section doesn't appear in about:support, and in about:profiles the current profile is marked as "This profile is in use by another application and it cannot be deleted." There may be other oddities. This doesn't fail to restart because we don't require a known profile unless we're restarting to reset a profile, normally we just need a directory.

# Summary, solutions

In summary, a real mess. I think I can fix the immediate issue here by cloning and resolving the paths before comparing them in `GetProfileForDir`. That doesn't fix Mode B, for that we could separately make sure the root directory of the selected profile was resolved before we get to `nsXREDirProvider::SetProfile()` (though what about paths that don't exist yet?)

In bug 1513172 comment 3, :bobowen suggested we might avoid resolving the path for "ProfD", but that might be tricky, and at this point I don't know if we want to "fix" it, as there may be installs.ini or profiles.ini that rely on this by now.

At the same time, I'm concerned that this inconsistency could have some latent issues. Testing so far seems to only have turned up this one, there's also Mode B. Some may only be exposed when a significant population is on MSIX, until then it'd be rare to have profile and install paths that resolve inequal. Maybe this or something similar is also responsible for bug 1721488 (jumplists, as it relates to install paths) or bug 1728161 (overeager remoting, as it may relate to profile paths).

---

[1] Note that this doesn't happen if the package creates its profile after an unpackaged Firefox had already run. If the top level `AppData\Roaming\Mozilla` path already existed on the real filesystem, then that will be used instead of the package's private location, so the final path would be the same (up to shortnames).

[2] The `nsIFile` is passed through [`SelectProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4501-4503), [`SelectStartupProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2707-2709), and [`GetDefaultProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1736-1751), though there are a whole lot of other possibilities in `SelectStartupProfile` and `XRE_mainStartup` which get the `nsIFile` from different places. For instance [3] with a non-profile-reset restart.

[3] In this case `mProfD` had been made fresh [from `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1303), passed back from `SelectStartupProfile` [here](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1364).
# Setup: Normal Run

The profile directory gets sent to the directory provider/service [in `XRE_mainStartup()`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730). `nsXREDirProvider::SetProfile()` saves a reference to the profile root directory to return for "ProfD", but first it [resolves that path](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsXREDirProvider.cpp#233-239) (due to bug 1369670). A profile path initially looks like:

```C:\Users\agash\AppData\Roaming\Mozilla\Profiles\usjl8hcn.default-beta```

If that's only a virtual path, and the profile is actually in a package's private location, this resolves to a final form like:

```C:\Users\agash\AppData\Local\Packages\Mozilla.Firefox.Beta_gmpnhwe7bv608\LocalCache\Roaming\Mozilla\Firefox\Profiles\usjl8hcn.default-beta```

This introduces a potential inconsistency between the profile service's list of profiles and the directory service's "ProfD" [1].

# Restart for Profile Reset

1. When shutting down for restart, "ProfD" is [saved](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#278) and used to [set `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#146-148).
2. On restart, `nsToolkitProfileService::SelectStartupProfile()` will try to get a profile [using `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1301).
3. `GetProfileByDir()` looks for a profile with an [equal root directory](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/toolkit/profile/nsToolkitProfileService.cpp#1884).
4. `Equals` does some canonicalization but [only up to short paths](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/io/nsLocalFileWin.cpp#2950-2959) on Windows, so the paths won't match, and no profile is passed out of `SelectStartupProfile()`.
5. Because we're trying to do a profile reset, [`SelectProfile()` fails](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2737-2740).
6. Firefox [exits](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4504-4507).

# Why is this not prevented by resetSupported?

`ResetProfile.resetSupported()` is supposed to detect that this would happen. It checks that the current profile is known to the profile manager, using [roughly the same logic](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/modules/ResetProfile.jsm#36-45). If not found it should hide the "Refresh Firefox..." button on about:support and elsewhere.

The problem is that `nsXREDirProvider::SetProfile()` is [called with `mProfD`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730), and when it resolves the path it modifies the `nsIFile` that was passed in. If we had selected a default profile, this is the same `nsIFile` that is used to store the profile's root dir in the profile service [2]. `SetProfile()` modifies the path when resolving it, so they'll always match in this case. This can be seen in about:profiles in a package: Only the root directory of the current profile is resolved, and it is still recognized as the current profile (showing "This is the profile in use and it cannot be deleted"), though see Mode B below.

# Failure Mode B

There's another failure mode, call it Mode B: After a non-profile-reset restart, e.g. "Restart normally..." in about:profiles, the profile list never gets a resolved root path for the active profile, though "ProfD" in the dirsvc is resolved, because these are different `nsIFile`s [3]. As a result the "Refresh Firefox..." section doesn't appear in about:support, and in about:profiles the current profile is marked as "This profile is in use by another application and it cannot be deleted." There may be other oddities. This doesn't fail to restart because we don't require a known profile unless we're restarting to reset a profile, normally we just need a directory.

# Summary, solutions

In summary, a real mess. I think I can fix the immediate issue here by cloning and resolving the paths before comparing them in `GetProfileForDir`. That doesn't fix Mode B, for that we could separately make sure the root directory of the selected profile was resolved before we get to `nsXREDirProvider::SetProfile()` (though what about paths that don't exist yet?)

In bug 1513172 comment 3, :bobowen suggested we might avoid resolving the path for "ProfD", but that might be tricky, and at this point I don't know if we want to "fix" it, as there may be installs.ini or profiles.ini that rely on this by now.

At the same time, I'm concerned that this inconsistency could have some latent issues. Testing so far seems to only have turned up this one, there's also Mode B. Some may only be exposed when a significant population is on MSIX, until then it'd be rare to have profile and install paths that resolve inequal. Maybe this or something similar is also responsible for bug 1721488 (jumplists, as it relates to install paths) or bug 1728161 (overeager remoting, as it may relate to profile paths).

---

[1] Note that this doesn't happen if the package creates its profile after an unpackaged Firefox had already run. If the top level `AppData\Roaming\Mozilla` path already existed on the real filesystem, then that will be used instead of the package's private location, so the final path would be the same (up to shortnames).

[2] The `nsIFile` is passed through [`SelectProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4501-4503), [`SelectStartupProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2707-2709), and [`GetDefaultProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1736-1751), though there are a whole lot of other possibilities in `SelectStartupProfile` and `XRE_mainStartup` which get the `nsIFile` from different places. For instance [3] with a non-profile-reset restart.

[3] In this case `mProfD` had been made fresh [from `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1303), passed back from `SelectStartupProfile` [here](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1364).
# Setup: Normal Run

The profile directory gets sent to the directory provider/service [in `XRE_mainStartup()`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730). `nsXREDirProvider::SetProfile()` saves a reference to the profile root directory to return for "ProfD", but first it [resolves that path](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsXREDirProvider.cpp#233-239) (due to bug 1369670). A profile path initially looks like:

```C:\Users\agash\AppData\Roaming\Mozilla\Profiles\usjl8hcn.default-beta```

If that's only a virtual path, and the profile is actually in a package's private location, this resolves to a final form like:

```C:\Users\agash\AppData\Local\Packages\Mozilla.Firefox.Beta_gmpnhwe7bv608\LocalCache\Roaming\Mozilla\Firefox\Profiles\usjl8hcn.default-beta```

This introduces a potential inconsistency between the profile service's list of profiles and the directory service's "ProfD" [1].

# Restart for Profile Reset

1. When shutting down for restart, "ProfD" is [saved](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#278) and used to [set `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#146-148).
2. On restart, `nsToolkitProfileService::SelectStartupProfile()` will try to get a profile [using `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1301).
3. `GetProfileByDir()` looks for a profile with an [equal root directory](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/toolkit/profile/nsToolkitProfileService.cpp#1884).
4. `Equals` does some canonicalization but [only up to short paths](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/io/nsLocalFileWin.cpp#2950-2959) on Windows, so the paths won't match, and no profile is passed out of `SelectStartupProfile()`.
5. Because we're trying to do a profile reset, [`SelectProfile()` fails](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2737-2740).
6. Firefox [exits](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4504-4507).

# Why is this not prevented by resetSupported?

`ResetProfile.resetSupported()` is supposed to detect that this would happen. It checks that the current profile is known to the profile manager, using [roughly the same logic](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/modules/ResetProfile.jsm#36-45). If not found it should hide the "Refresh Firefox..." button on about:support and elsewhere.

The problem is that `nsXREDirProvider::SetProfile()` is [called with `mProfD`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730), and when it resolves the path it modifies the `nsIFile` that was passed in. If we had selected a default profile, this is the same `nsIFile` that is used to store the profile's root dir in the profile service [2]. So they'll always match in this case, even when `SetProfile()` modifies the path when resolving it. This can be seen in about:profiles in a package: Only the root directory of the current profile is resolved, and it is still recognized as the current profile (showing "This is the profile in use and it cannot be deleted"), though see Mode B below.

# Failure Mode B

There's another failure mode, call it Mode B: After a non-profile-reset restart, e.g. "Restart normally..." in about:profiles, the profile list never gets a resolved root path for the active profile, though "ProfD" in the dirsvc is resolved, because these are different `nsIFile`s [3]. As a result the "Refresh Firefox..." section doesn't appear in about:support, and in about:profiles the current profile is marked as "This profile is in use by another application and it cannot be deleted." There may be other oddities. This doesn't fail to restart because we don't require a known profile unless we're restarting to reset a profile, normally we just need a directory.

# Summary, solutions

In summary, a real mess. I think I can fix the immediate issue here by cloning and resolving the paths before comparing them in `GetProfileForDir`. That doesn't fix Mode B, for that we could separately make sure the root directory of the selected profile was resolved before we get to `nsXREDirProvider::SetProfile()` (though what about paths that don't exist yet?)

In bug 1513172 comment 3, :bobowen suggested we might avoid resolving the path for "ProfD", but that might be tricky, and at this point I don't know if we want to "fix" it, as there may be installs.ini or profiles.ini that rely on this by now.

At the same time, I'm concerned that this inconsistency could have some latent issues. Testing so far seems to only have turned up this one, there's also Mode B. Some may only be exposed when a significant population is on MSIX, until then it'd be rare to have profile and install paths that resolve inequal. Maybe this or something similar is also responsible for bug 1721488 (jumplists, as it relates to install paths) or bug 1728161 (overeager remoting, as it may relate to profile paths).

---

[1] Note that this doesn't happen if the package creates its profile after an unpackaged Firefox had already run. If the top level `AppData\Roaming\Mozilla` path already existed on the real filesystem, then that will be used instead of the package's private location, so the final path would be the same (up to shortnames).

[2] The `nsIFile` is passed through [`SelectProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4501-4503), [`SelectStartupProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2707-2709), and [`GetDefaultProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1736-1751), though there are a whole lot of other possibilities in `SelectStartupProfile` and `XRE_mainStartup` which get the `nsIFile` from different places. For instance [3] with a non-profile-reset restart.

[3] In this case `mProfD` had been made fresh [from `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1303), passed back from `SelectStartupProfile` [here](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1364).
# Setup: Normal Run

The profile directory gets sent to the directory provider/service [in `XRE_mainStartup()`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730). `nsXREDirProvider::SetProfile()` saves a reference to the profile root directory to return for "ProfD", but first it [resolves that path](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsXREDirProvider.cpp#233-239) (due to bug 1369670). A profile path initially looks like:

```C:\Users\agash\AppData\Roaming\Mozilla\Profiles\usjl8hcn.default-beta```

If that's only a virtual path, and the profile is actually in a package's private location, this resolves to a final form like:

```C:\Users\agash\AppData\Local\Packages\Mozilla.Firefox.Beta_gmpnhwe7bv608\LocalCache\Roaming\Mozilla\Firefox\Profiles\usjl8hcn.default-beta```

This introduces a potential inconsistency between the profile service's list of profiles and the directory service's "ProfD" [1].

# Restart for Profile Reset

1. When shutting down for restart, "ProfD" is [saved](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#278) and used to [set `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/base/AppShutdown.cpp#146-148).
2. On restart, `nsToolkitProfileService::SelectStartupProfile()` will try to get a profile [using `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1301).
3. `GetProfileByDir()` looks for a profile with an [equal root directory](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/toolkit/profile/nsToolkitProfileService.cpp#1884).
4. `Equals` does some canonicalization but [only up to short paths](https://searchfox.org/mozilla-central/rev/1749ba14c2ebe200855802c478780122135727f2/xpcom/io/nsLocalFileWin.cpp#2950-2959) on Windows, so the paths won't match, and no profile is passed out of `SelectStartupProfile()`.
5. Because we're trying to do a profile reset, [`SelectProfile()` fails](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2737-2740).
6. Firefox [exits](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4504-4507).

# Why is this not prevented by resetSupported?

`ResetProfile.resetSupported()` is supposed to detect that this would happen. It checks that the current profile is known to the profile manager, using [roughly the same logic](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/modules/ResetProfile.jsm#36-45). If not found it should hide the "Refresh Firefox..." button on about:support and elsewhere.

The problem is that `nsXREDirProvider::SetProfile()` is [called with `mProfD`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4730), and when it resolves the path it modifies the `nsIFile` that was passed in. If we had selected a default profile, this is the same `nsIFile` that is used to store the profile's root dir in the profile service [2]. So they'll always match in this case, even when `SetProfile()` modifies the path when resolving it. This can be seen in about:profiles in a package: Only the root directory of the current profile is resolved, and it is still recognized as the current profile (showing "This is the profile in use and it cannot be deleted"), though see Mode B below.

# Failure Mode B

There's another failure mode, call it Mode B: After a non-profile-reset restart, e.g. "Restart normally..." in about:profiles, the profile list never gets a resolved root path for the active profile, though "ProfD" in the dirsvc is resolved, because these are different `nsIFile`s [3]. As a result the "Refresh Firefox..." section doesn't appear in about:support, and in about:profiles the current profile is marked as "This profile is in use by another application and it cannot be deleted." There may be other oddities. This doesn't fail to restart because we don't require a known profile unless we're restarting to reset a profile, normally we just need a directory.

# Summary, solutions

In summary, a real mess. I think I can fix the immediate issue here by cloning and resolving the paths before comparing them in `GetProfileForDir`. That doesn't fix Mode B, for that we could separately make sure the root directory of the selected profile was resolved before we get to `nsXREDirProvider::SetProfile()` (though what about paths that don't exist yet?)

In bug 1513172 comment 3, :bobowen suggested we might avoid resolving the path for "ProfD", but that might be tricky, and at this point I don't know if we want to "fix" it, as there may be installs.ini or profiles.ini that rely on this by now.

At the same time, I'm concerned that this inconsistency could have some latent issues. Testing so far seems to only have turned up this one, there's also Mode B. Some may only be exposed when a significant population is on MSIX, until then it'd be rare to have profile or install paths that change when resolved. Maybe this or something similar is also responsible for bug 1721488 (jumplists, as it relates to install paths) or bug 1728161 (overeager remoting, as it may relate to profile paths).

---

[1] Note that this doesn't happen if the package creates its profile after an unpackaged Firefox had already run. If the top level `AppData\Roaming\Mozilla` path already existed on the real filesystem, then that will be used instead of the package's private location, so the final path would be the same (up to shortnames).

[2] The `nsIFile` is passed through [`SelectProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#4501-4503), [`SelectStartupProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/xre/nsAppRunner.cpp#2707-2709), and [`GetDefaultProfile`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1736-1751), though there are a whole lot of other possibilities in `SelectStartupProfile` and `XRE_mainStartup` which get the `nsIFile` from different places. For instance [3] with a non-profile-reset restart.

[3] In this case `mProfD` had been made fresh [from `XRE_PROFILE_PATH`](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1303), passed back from `SelectStartupProfile` [here](https://searchfox.org/mozilla-central/rev/a276135f5459fce19fa710337244d4dcdc4289ee/toolkit/profile/nsToolkitProfileService.cpp#1364).

Back to Bug 1727878 Comment 2