Affected versions

• 95.0a1
• 94.0b8

Affected platforms

• Windows 11 x64

Preconditions

• clean environment - all profiles and profiles.ini are deleted

Steps to reproduce

1. Install normal Firefox.exe and open it.
2. Instal Firefox MSIX and Launch it.
3. After the message with Firefox already running is displayed Close the normal Firefox instance.
4. Click the Close Firefox button.

Expected result

• Firefox MSIX is opened and the importing window is displayed.

Actual result

• No import window is displayed and a Firefox instance is opened with disabled updates and the About Firefox window does not contain “Windows MSIX package”.

Regression range

• Not a regression. Happens with the implementation of bug 1733999.

Notes

• Attached a screen recording: link.
• This issue is reproducing even if waiting for the normal Firefox process to close. I see that somehow the import is performed without the window. Bookmarks, history, etc. are displayed in the newly opened Firefox instance but from what I see this is not an MSIX instance because is missing the MSIX package message in about Firefox.

Notably, the profile import may still be done in this scenario. In my own testing, I browsed to slashdot.org in the first Firefox instance before installing & launching the MSIX version. After launching the MSIX one, getting the error, closing the old Firefox, and clicking "Close Firefox", I was able to see that in the MSIX version's history even though the import dialog was not shown, and despite the other weirdness (like the About dialog not showing MSIX information).

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

Notably, the profile import may still be done in this scenario. In my own testing, I browsed to slashdot.org in the first Firefox instance before installing & launching the MSIX version. After launching the MSIX one, getting the error, closing the old Firefox, and clicking "Close Firefox", I was able to see that in the MSIX version's history even though the import dialog was not shown, and despite the other weirdness (like the About dialog not showing MSIX information).

This strongly suggests the update directories were shared, which might explain some things.

I dug into this a bit more. tl;dr - it appears that the MSIX version runs with the non-MSIX profile in this scenario.

On the About dialog looking strange, that seems controlled by the distribution.id pref (per https://searchfox.org/mozilla-central/rev/2e3b0483e31abffe0b4374480a34c6d23f5186ea/browser/base/content/aboutDialog.js#26). I compared the output of Services.prefs.getCharPref("distribution.id"). When in the strange state, that throws this exception:

@debugger eval code:1:16
getEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:243:24
exports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:167:14
evaluateJS@resource://devtools/server/actors/webconsole.js:1131:38
evaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1023:35
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22

After a relaunch, it returns "mozilla-MSIX", as expected.

The other thing I compared was the profiles directory. While in the strange state, there are two profiles present. One is "xxxxxx.default" and the other is "xxxxxxx.default-nightly". The former only has a times.json in it with a created and firstUse key in it. The latter is a full profile that appears to be locked and in use, and lines up with the one that about:support shows.

After a relaunch, a third profile shows up, named as xxxxxxxx.default-nightly-$timestamp, and shows up in about:support.

So, it's pretty clear that the MSIX version is using the non migrated profile when in this weird state. Which certainly explains why it can see history from the other profile without any obvious migration of it, and I suspect it also explains the weird update dialog. (I don't know exactly why yet, but perhaps something in the non-MSIX profile prevents it from seeing the distribution prefs?)

I imagine that fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1736702 would fix this, but I also wonder if there's a relatively easy way we can detect this state and prevent it from launching after the user clicks "Close Firefox" after closing the non-MSIX Firefox. That's probably a good thing anyways, as a Firefox popping up after clicking "Close Firefox" really doesn't match expectations.

(In reply to Nick Alexander :nalexander [he/him] from comment #2)

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

Notably, the profile import may still be done in this scenario. In my own testing, I browsed to slashdot.org in the first Firefox instance before installing & launching the MSIX version. After launching the MSIX one, getting the error, closing the old Firefox, and clicking "Close Firefox", I was able to see that in the MSIX version's history even though the import dialog was not shown, and despite the other weirdness (like the About dialog not showing MSIX information).

This strongly suggests the update directories were shared, which might explain some things.

I might be misunderstanding, but as far as I know, the updater was never run in this scenario, so I'm not sure how this factors in?

https://bugzilla.mozilla.org/show_bug.cgi?id=1742385 hitting this same weirdness piqued my curiosity here again, so I dug in a little bit more, this time with Process Explorer, and discovered that after the first launch of the MSIX package (when we're in a funky state), XRE_PROFILE_PATH and XRE_PROFILE_LOCAL_PATH are not set in the environment. After shutting it down and relaunching it, they are.

I don't understand the startup process to know whether or not this is expected or not, but it's a notable difference at least. I saw no other differences in the env or command line used when launching.

Possibly the same root cause as https://bugzilla.mozilla.org/show_bug.cgi?id=1730498