Closed Bug 1728161 Opened 3 years ago Closed 3 years ago

Microsoft Store Launch button redirects to already running `C:\Program Files\Mozilla Firefox\firefox.exe`

Categories

(Firefox :: Installer, defect)

Product:
Firefox
Component:
Installer
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: nalexander, Assigned: nalexander)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fidedi-tikka])

I have put "Mozilla Firefox Beta" into the Microsoft Store under a private audience: https://partner.microsoft.com/en-us/dashboard/products/9P9GJR8PH8TT/overview. This is a hand-rolled MSIX: I'll land patches to produce, or documentation for how to produce, these Store-specific MSIX packages sometime soon. The MSIX is a repackage of a mozilla-beta build.

The Launch button in the Microsoft Store redirects to an already running Firefox Release at C:\Program Files\Mozilla Firefox\firefox.exe. My guess is that this is working as expected: Beta launches, looks for existing instances, does that thing where Release and Beta look the same, and redirects to the running Firefox Release instance. Maybe we want to do less of that when we are a packaged app?

When Firefox Release is not already running, we launch Beta as expected: from C:\Program Files\WindowsApps\MozillaFoundation.MozillaFirefoxBeta_92.0.0.0_x64__1asrjg2sqer5r\VFS\ProgramFiles\MozillaFirefox Beta Package Root\firefox.exe.

mhowell: do you think we should try to make remoting only apply to the specific App Package? I personally do. Or maybe this is a Romain domain (hehe)?

Flags: needinfo?(mhowell)

So, that should already be happening after the first run of the package, because the remote instance is selected partially based on the profile name. For the first run though, does the profile being open in another instance block migrating from it? If not, then I like your idea, but if that means we wouldn't be able to migrate the profile, then that's a harder question and I don't have an answer right now...

Flags: needinfo?(mhowell)

I'm calling this an S3, since Firefox does still technically work.

Severity: -- → S3

Adam suggests that this is not so unlikely; this will be next on my list.

Assignee: nobody → nalexander
Status: NEW → ASSIGNED

For what it's worth, I have updated the package in the Microsoft Store to 93.0b9 (from https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=2d7f438e5a02611c866bfd0df6342e8e47b90c01) and I no longer see this. I open Firefox Release 92.0 from C:\Program Files\Mozilla Firefox\firefox.exe, I navigate to Mozilla Firefox Beta in the Microsoft Store (via ms-windows-store://pdp/?productid=9P9GJR8PH8TT) and when I tap "Launch" in the Store, Beta opens (from C:\Program Files\WindowsApps\MozillaFoundation.MozillaFirefoxBeta_93.0.1.0_x64__1asrjg2sqer5r\VFS\ProgramFiles\Mozilla Firefox Beta Package Root\firefox.exe).

Further, if I uninstall Mozilla Firefox Beta by finding it in the Run... list and selecting "Uninstall", and then I reinstall from ms-windows-store://pdp/?productid=9P9GJR8PH8TT, and then I tap "Launch" in the Store, Beta opens.

So perhaps this doesn't reproduce? atrif, can you check this out?

Flags: needinfo?(alexandru.trif)

I can still reproduce this in a clean environment only, so the STR are:

  1. Have no other Firefox MSIX or normal Firefox profiles.
  2. Install and open Firefox .exe 92.0 or 93.0b8.
  3. Install and open Firefox MSIX from the store.

At step three if we click Open inside the store while firefox 92.0 is running it will open another 92.0 instance. This can be fixed if we close 92.0, run MSIX from the store for import to happen, and repeat the above steps. After doing this when clicking open from the store while 92.0 is opened, Firefox MSIX will be displayed. I also did a screen recording for a better understanding when starting with a clean environment (all previous mozilla profiles are deleted). Link to screen recording: here. MSIX is uninstalled and installed again from the store and opened at the end. If more information is needed please let me know. Thank you!

Flags: needinfo?(alexandru.trif)

Also, I saw today that when installing Firefox .exe after Firefox MSIX is installed there is no way to open Firefox MSIX and Firefox.exe at the same time. Even double-clicking desktop image while having MSIX open will open another MSIX instance, or while having Firefox.exe opened and trying to open MSIX from the store will open another Firefox.exe instance.

OK, I can reproduce this with a clean environment, meaning no Profiles and no profiles.ini. Exactly as :atrif says.

Digging in.

There's an interaction here with profile selection and profile migration, exactly as :mhowell posited in https://bugzilla.mozilla.org/show_bug.cgi?id=1728161#c2.

I propose to extend the mechanisms of Bug 1709131 to keep the package identity in some usable form, and then to include it when appropriate in the "remoting class name" used to group instances: https://searchfox.org/mozilla-central/rev/b022ae1fc071ad7a29f64f281bc19b7b093df538/toolkit/components/remote/RemoteUtils.h#12.

It's not trivial to test if having a profile open in a non-MSIX Firefox blocks migration from that profile because of this issue. But I suppose I could run a Firefox Nightly against that profile, which won't be grouped as the MSIX Beta I have installed, to test. If I can work through the profile downgrade issues, which I'm not sure I'll be able to. Maybe if I launch the non-MSIX Firefox with the remote server off I can test this. Yes, that should work. Let me try that now.

It's not trivial to test if having a profile open in a non-MSIX Firefox blocks migration from that profile because of this issue. But I suppose I could run a Firefox Nightly against that profile, which won't be grouped as the MSIX Beta I have installed, to test. If I can work through the profile downgrade issues, which I'm not sure I'll be able to. Maybe if I launch the non-MSIX Firefox with the remote server off I can test this. Yes, that should work. Let me try that now.

Oh dear. If I launch the non-MSIX Firefox with c:/Program Files/Mozilla Firefox/firefox.exe --no-remote, then the MSIX Beta will indeed launch. Unfortunately, it shows the skeleton UI and then spins for a while, presumably as it tries to lock the default profile in use by the non-MSIX Firefox. It then pops the "Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window." dialog.

This is perhaps not a terrible outcome, though: at least it's clear what the user needs to do to make progress. They may be surprised later to discover that the two can run side-by-side after the initial import, of course. It's probably tricky to make that message say something about profile migration/import, since we might not know we need to do migration/import so early, but we could consider it.

This isn't the subject of this ticket, but after doing the migration/import, my Firefox release now complains about profile downgrade, because the MSIX Beta opened it :(

At least this won't be an issue in the common case, with release Firefox installed and folks trying out release Firefox from the Microsoft Store.

bhearsum: the small technical change for this ticket requires a little light C++ massaging: see https://bugzilla.mozilla.org/show_bug.cgi?id=1728161#c9. One wrinkle is that it sure looks like the existing place keeping this information, namely WinUtils/sysinfo, is initialized well after the remote server is configured. So we may need to rearrange some deckchairs to cache this early and then access it from that location. Adam, Molly, and I can help as needed.

We aren't going to be able to slide this into 94 Nightly, so the immediate time pressure is off. Would you like to have the first cut at this?

Flags: needinfo?(bhearsum)

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

bhearsum: the small technical change for this ticket requires a little light C++ massaging: see https://bugzilla.mozilla.org/show_bug.cgi?id=1728161#c9. One wrinkle is that it sure looks like the existing place keeping this information, namely WinUtils/sysinfo, is initialized well after the remote server is configured. So we may need to rearrange some deckchairs to cache this early and then access it from that location. Adam, Molly, and I can help as needed.

We aren't going to be able to slide this into 94 Nightly, so the immediate time pressure is off. Would you like to have the first cut at this?

I think so. I assume this needs to be fixed before 94 hits Release?

Flags: needinfo?(bhearsum)

We expect press coverage on Firefox launch and it seems realistic that initial store installers will be existing Firefox users just trying it out.
I don't think this should block releasing with 94 but certainly highly desirable to avoid confusions.

Depends on: 1733999

There's nothing private about the actual work to be done here, so I've spun out the remoting disambiguation to https://bugzilla.mozilla.org/show_bug.cgi?id=1733999 and doing better migrating a profile that is in use to https://bugzilla.mozilla.org/show_bug.cgi?id=1734000.

Depends on: 1734000
Whiteboard: [fidedi-tikka]

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

It's not trivial to test if having a profile open in a non-MSIX Firefox blocks migration from that profile because of this issue. But I suppose I could run a Firefox Nightly against that profile, which won't be grouped as the MSIX Beta I have installed, to test. If I can work through the profile downgrade issues, which I'm not sure I'll be able to. Maybe if I launch the non-MSIX Firefox with the remote server off I can test this. Yes, that should work. Let me try that now.

Oh dear. If I launch the non-MSIX Firefox with c:/Program Files/Mozilla Firefox/firefox.exe --no-remote, then the MSIX Beta will indeed launch. Unfortunately, it shows the skeleton UI and then spins for a while, presumably as it tries to lock the default profile in use by the non-MSIX Firefox. It then pops the "Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window." dialog.

This is perhaps not a terrible outcome, though: at least it's clear what the user needs to do to make progress. They may be surprised later to discover that the two can run side-by-side after the initial import, of course. It's probably tricky to make that message say something about profile migration/import, since we might not know we need to do migration/import so early, but we could consider it.

Just to follow-up here for posterity, with my patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1733999 applied, the behaviour is indeed "Firefox is already running..." if you:

  1. Start from a clean slate of profiles
  2. Run regular Firefox (without --no-remote)
  3. Run MSIX Firefox
Depends on: 1736876

Now that Bug 1733999 (per package remoting) and Bug 1736876 (stop migrating profiles into App Package on first run) have landed, this is no longer an issue.

Group: mozilla-employee-confidential
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
No longer depends on: 1734000
You need to log in before you can comment on or make changes to this bug.