Closed Bug 1709131 Opened 3 years ago Closed 3 years ago

Add `nsSystemInfo` runtime flag for whether running application is a packaged Microsoft Windows app

Categories

(Firefox :: Installer, task)

task

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox92 --- fixed

People

(Reporter: nalexander, Assigned: agashlin)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.

Assignee: nobody → agashlin
Status: NEW → ASSIGNED

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.

See Also: → 1709892

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.

Blocks: 1710908
No longer blocks: 1710908
Group: partner-confidential
Group: partner-confidential
Group: partner-confidential
Pushed by agashlin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/90f9b53ff945 Report whether the current process has a package identity. r=mhowell
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
Blocks: 1737177
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: