1789491 - Wrong shell command when installed through Microsoft store

Status: NEW

(Firefox :: Installer, defect, P3)

Description

[fredmoron]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

Install Firefox through Microsoft Store.
Set it as default Browser.

Actual results:

It creates registry
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice - progId

HKEY_CLASSES_ROOT{progId}\shell\open\command

But the command is like:
C:\Program Files\WindowsApps\Mozilla.Firefox_104.0.2.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\firefox.exe -osint -url "%1"
There are missing quotes aorund the firefox.exe path.
"ProgId

Expected results:

The registry should have
"C:\Program Files\WindowsApps\Mozilla.Firefox_104.0.2.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\firefox.exe" -osint -url "%1"
the path with quotes like when it is installed from the .exe from firefox website.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Installer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Nick Alexander :nalexander [he/him]]

Thanks for the report! This does sound like it's a plausible bug, but I'm not sure we can address it: these registry entries are created, I think by the MSIX installation process and not by Firefox per se. But perhaps quotation marks are accepted when specifying the path in the manifest XML?

bhearsum: at one point we wanted to rework the layout of the package, which might be an opportunity to tidy this up.

Comment 3

[[e-mail] (:bhearsum)]

Does this actually cause any issues? It looks to me like MSIX ProgIDs have separate keys in HKEY_CLASSES_ROOT\AppXycpy9mb5aa9x31qd69xmfqbdxkq7ra6z\Shell\open for the executable and the parameters (PackageRelativeExecutable and Parameters), which would explain why opening links seems to work fine. If I monkey with those I'm able to break it though, eg: by changing PackageRelativeExecutable to something that doesn't exist within the package.

Comment 4

[fredmoron]

Microsoft Power Toys uses this with powertoys run to launch default Browser. Works with Firefox installed using .exe but fails if installed through Microsoft Store. Also works for chrome, brave...

Comment 5

[[e-mail] (:bhearsum)]

(In reply to fredmoron from comment #4)

Microsoft Power Toys uses this with powertoys run to launch default Browser. Works with Firefox installed using .exe but fails if installed through Microsoft Store. Also works for chrome, brave...

Thanks for the quick response! Arguably, this is a bug in Power Toys or one of its plugins, but if we can do something to make it less problematic we ought to do it.

I did a few quick tests myself and found that explicitly opening Firefox from alt+space and clicking one of the "Learn More" links in the UI worked fine -- but doing a web search with it did not (I got a "Failed to open..." dialog, which I presume is what you're seeing).

I ended up opening https://github.com/microsoft/PowerToys/issues/20365 about the WebSearch plugin as well, since it probably ought to be reading the command & parameters differently for MSIX packages.

Comment 6

[Nick Rishel [:nrishel]]

To resolve it we would need a way to specify the full path of the executable in AppxManifest.xml via some manifest variable as opposed the current package relative path or we would need to move the executable outside of the virtualized directory, because we would need to quote C:\Program Files.... I couldn't find any manifest variables when investigating, and I don't think we want to move the exe outside of VFS. I think our hands might be tied by the manifest scheme.

Comment 7

[Nick Rishel [:nrishel]]

Removing regression; behavior has always been present for MSIX packages.

Comment 8

[[e-mail] (:bhearsum)]

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

To resolve it we would need a way to specify the full path of the executable in AppxManifest.xml via some manifest variable as opposed the current package relative path or we would need to move the executable outside of the virtualized directory, because we would need to quote C:\Program Files.... I couldn't find any manifest variables when investigating, and I don't think we want to move the exe outside of VFS. I think our hands might be tied by the manifest scheme.

I agree that there doesn't seem to be a viable way to fix this bug while maintaining the spaces in the path.

Just to re-iterate it though, Nick pointed out that fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1736113 would have the effect of removing the spaces from the path -- which would likely fix this bug.

Comment 9

[Nick Rishel [:nrishel]]

I think we discussed this offline, but to document this inline: normalizing the path wouldn't remove all spaces since the normalized virtual directory remains a grandchild of Program Files.

Comment 10

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue using comment 0 steps with Firefox 105.0.3 MSIX installed from the Store and 106.0 MSIX / 107.0a1 (2022-10-12) MSIX/ 102.04.0esr MSIX installed from treeherder. Setting this to new per the above comments.