Closed Bug 1733284 Opened 4 months ago Closed 2 months ago

LaunchUnelevated fails with packaged app on Windows 10


(Firefox :: General, defect)




96 Branch
Tracking Status
firefox96 --- verified


(Reporter: agashlin, Assigned: bhearsum)


(Blocks 1 open bug)


(Whiteboard: [fidedi-tikka])


(2 files)

If Firefox is run with an elevated integrity level (for instance from an elevated installer such as Fiddler Classic), the launcher process will attempt to relaunch it unelevated by re-running the .exe through the shell. This won't work if Firefox is installed as an MSIX package, there is no permission for anyone to directly execute the .exe within the package's VFS (to prevent issues like bug 1732907), so there is an error "Windows cannot access the specified device, file, or path" from Explorer.

In a package context, we should give Explorer the path to the Firefox app within the package as shell:appsFolder\<Package Family Name>\FIREFOX instead of using the .exe name.

This was observed above on Windows 10 21H1 (19043.1202). It doesn't seem to occur on the latest Windows 11 beta (22000.194). Here, we still LaunchUnelevated(), but it seems that Explorer (or CreateProcess) is able to figure out what to do when given the path of the packaged exe that doesn't have normal execute permissions. The launched Firefox does have the proper package identity.

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

Component: General → Installer

Bug 1731261 may be related to this, though maybe not since it shows no error message and that issue occurs on Windows 11.

Setting S3 severity since there seems to be a pretty clear workaround.

Severity: -- → S3

While a lot of MSIX bugs are in Firefox::Installer, this is about the launch unelevated functionality, which doesn't have much to do with the installation of Firefox.

Component: Installer → General
Assignee: nobody → nalexander
Whiteboard: [fidedi-tikka]

This re-arranges some deckchairs, allowing to have the launcher
process query the Windows packaged app environment.

Depends on D129882

Ben is going to push this forward.

Assignee: nalexander → bhearsum
Attachment #9248893 - Attachment description: WIP: Bug 1733284 - Part 1: Expose Windows packaged app utilities to code outside of XUL. r?mhowell → Bug 1733284: Part 1: Expose Windows packaged app utilities to code outside of XUL. r?mhowell!
Pushed by
Part 1: Expose Windows packaged app utilities to code outside of XUL. r=mhowell
Part 2: Re-launch Firefox with an App path when running in a package context r=mhowell,tkikuchi
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch

Reproduced the issue on Windows 10 with 96.0a1 (2021-11-17). We verified the fix for 96.0a1 (2021-11-18) on two different systems on both Windows 10 and 11 by using the STR from Bug 1731261. Please let me or atrif know if we need to do additional testing here.

Duplicate of this bug: 1748983
You need to log in before you can comment on or make changes to this bug.