(In reply to Ed Lee :Mardak from comment #6)
Notably, PackageManager class has
[Windows.Foundation.Metadata.DualApiPartition(version=1)] attribute while TaskbarManager doesn't. Is that distinction what allows calling via C++/WinRT language projection? widget/windows/OSKInputPaneManager.cpp uses InputPane, widget/windows/ToastNotificationHandler.h uses ToastNotifier, and widget/windows/WindowsUIUtils.cpp uses UIViewSettings -- all of those classes indeed have DualApiPartitionAttribute.
Yeah it looks like DualApiPartition is the thing to look for, according to this document, "APIs that have the DualApiPartition are supported in all desktop apps, including those with package identity and those without package identity." That doc also lists APIs supported in desktop apps with package identity, it claims to be exhaustive and does not include TaskbarManager, so I think this is as close as we can get to documentation that it is not supported.
(In reply to Ed Lee :Mardak from comment #8)
I found a video of someone using the API and this is what it would look like (attached). So even if we get say the defaultagent working as a full UWP with Firefox passing along a user initiated event to get WDBA to respond, is this the UX we want (where we would also probably need to figure out what launching WDBA to launch Firefox would look like)? (Where the premise is converting something smaller to UWP might be easier than all of Firefox as in bug 1162562.)
Where if the user needs to click something in Firefox to then need to confirm another windows prompt, maybe asking/showing the user would be a reasonable alternative along the lines of attachment 9197495 [details] from bug 1686343 comment 4.
I've experimented with a few sample apps, it doesn't look like we're going to be able to set the AUMID in a UWP app. We'd need this in order to get Windows to treat a helper app as part of the same taskbar group as Firefox. Using SetCurrentProcessExplicitAppUserModelID in the SparsePackages sample only works when it isn't running with Identity, with Identity it always appears in a different group. This doc says explicitly "You can't define custom AUMIDs." Thus if we used a standalone launcher app that could request pinning, the Firefox that launches wouldn't be grouped with the pin, cluttering the taskbar and causing confusion.
It's conceivable that we could set Firefox to use the AUMID that the package would use, Microsoft does provide a mechanism for migrating pins when installing a package. But this would required changing the ID in a lot of other places as well, especially for existing installs, and it would make multiple installs on a system indistinguishable. It might not even work in simple cases.
In conclusion, I don't think that pinning Firefox programmatically is feasible using any of the mechanisms I've learned about. Perhaps the best option is to provide a tutorial explaining how to manually pin if the user expresses interest in pinning.