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
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
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
After a relaunch, a third profile shows up, named as
xxxxxxxx.default-nightly-$timestamp, and shows up in
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.