To adjust behaviour depending on whether the application is a packaged Microsoft Windows app, we'll need a runtime flag. Luckily, there's an API for this: https://docs.microsoft.com/en-us/windows/win32/appxpkg/functions.

And, per :mhowell, https://docs.microsoft.com/en-us/windows/win32/api/appmodel/nf-appmodel-getcurrentpackageid returns a different error code for “not an app package” and “buffer not large enough”, which is handy.

This will be sibling to isMinGW.

See also isSnapEnvironment.

If there are no objections I'm going to put this in processInfo instead, given that this needs to do GetProcAddress it seemed like it fit in with the call to IsWow64Process2. See bug 1553546 which moved this and other stuff out of init for startup perf reasons.

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #2)

If there are no objections I'm going to put this in processInfo instead, given that this needs to do GetProcAddress it seemed like it fit in with the call to IsWow64Process2. See bug 1553546 which moved this and other stuff out of init for startup perf reasons.

No objections from me: wherever seems sensible.

The main drawback is this would require you to access it as (await Services.sysinfo.processInfo).hasPackageId instead of just Services.sysinfo.hasPackageId, which could only be called from async functions, and would probably need to be cached somewhere.

To make this as usable as possible, I backtracked on the sysinfo.processInfo approach. Instead it will be directly on sysinfo.hasWinPackageId, and also available in WinUtils.

Can we make this more generic since we have other packaged apps? Like just isPackaged?

And we can handle Flatpak/Snap/etc?

I recall :nalexander suggested something like this as well. My instinct is no, it feels like it's going to become too broad, and I don't have a good understanding of what properties of Appx/MSIX, Snap, Flatpak, maybe even .deb or RPM are all held in common. Feel free to change my mind, of course.

Well the situation you're encountering now is something they have in common (updates happening outside of Firefox), as well as the fact that legacy profiles will need to be turned on (https://searchfox.org/mozilla-central/source/toolkit/profile/nsToolkitProfileService.cpp#387).

This is only related to things that are Sandboxed/packaged, so MSIX, Snap, Flatpak. Unrelated to .deb or RPM.

(In reply to Mike Kaply [:mkaply] from comment #9)

Well the situation you're encountering now is something they have in common (updates happening outside of Firefox), as well as the fact that legacy profiles will need to be turned on (https://searchfox.org/mozilla-central/source/toolkit/profile/nsToolkitProfileService.cpp#387).

This is only related to things that are Sandboxed/packaged, so MSIX, Snap, Flatpak. Unrelated to .deb or RPM.

How the sandbox works, and how we intend to work with it, differs between packaging tech, though. For instance I don't think Flatpak uses legacy profiles currently, and we don't hide update UI in some places where it might be appropriate. I don't how much of this is intentional, but the important point is that I don't know. We're dealing with packaging on Windows, I'd rather not have to think beyond that for every one of the changes using this flag.

https://hg.mozilla.org/mozilla-central/rev/90f9b53ff945