Windows WinUI3/MSIX native messaging browser extension inaccessible from / incompatible with Firefox
Categories
(WebExtensions :: General, enhancement)
Tracking
(Not tracked)
People
(Reporter: minfrin, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Safari/605.1.15
Steps to reproduce:
Develop a native messaging browser extension using modern Windows WinUI3 packaged as an MSIX package (the only supported way to distribute a WinUI3 application).
Actual results:
MSIX packaging makes it impossible for the Firefox registry to be updated so that Firefox knows the extension exists.
This is a Windows MSIX packaging limitation.
Expected results:
Firefox requires a way for Windows WinUI3 applications packaged as MSIX to be found and recognised as a native messaging browser extension.
This in turn makes it impossible to deploy a Firefox native messaging browser extension from the Windows Store.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Shell Integration' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
Kicking this over to WebExtensions as I think this is their domain. This is likely a WebExtension spec request that should live in a w3c bugtracker.
n.b. to whomever looks at this from WebExtensions, I'm available to discuss the limitations of MSIX wrt registry writes. There are ways around this, e.g. using flexible virtualization. This works for self-distribution, but I have the impression it's fairly difficult to get approval for the Microsoft Store.
|
|
||
Comment 3•1 year ago
|
||
The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.
|
||
Comment 4•1 year ago
|
||
Reading the report and Comment 2, it appears you are proposing an enhancement.
I will mark the report accordingly and NeedInfo one of our developers to shed more light on the matter.
Thank you !
|
Reporter | |
Comment 5•1 year ago
|
||
(In reply to Nick Rishel [:nrishel] from comment #2)
Kicking this over to WebExtensions as I think this is their domain. This is likely a WebExtension spec request that should live in a w3c bugtracker.
n.b. to whomever looks at this from WebExtensions, I'm available to discuss the limitations of MSIX wrt registry writes. There are ways around this, e.g. using flexible virtualization. This works for self-distribution, but I have the impression it's fairly difficult to get approval for the Microsoft Store.
As I understand it, the web extensions spec describes how to communicate with a native extension, but not how to find a native extension. The use of the windows registry is a unique-to-windows thing. I don't know enough about MSIX packaging to know what options there are for discovery though, but I imagine whatever that discovery option is just needs to be used. I understand that an MSIX package can provide an executable that Firefox can execute, it's the telling Firefox it should even try part that's missing.
|
||
Comment 6•1 year ago
|
||
I just added this issue to the discussion points for our next bug triage and office hours meetings next week.
|
|
||
Updated•1 year ago
|
|
||
Comment 7•1 year ago
|
||
The native messaging API consists of three parts, ultimately to enable an extension in Firefox to launch and communicate an external application ("native messaging host"):
- A registration mechanism (docs) - applications external to Firefox/Chrome can write metadata to a specific location for use by these browsers.
- A launch mechanism - extensions within Firefox/Chrome can ask the browser to launch the native messaging host binary, and if permitted by the registration, the browser will do so.
- A communication protocol - a convention for the stdin/stdout wire format between the browser and the native messaging host binary. The binary is also passed the identifier of the extension so that it can know which extension was supposedly permitted.
To make sure that we are all on the same page:
- This bug is about a native messaging host packaged as a MSIX package. One of the features is isolation of the registry, which prevents apps within from writing to the Windows Registry (according to Microsoft's MSIX documentation), thus failing at the first part of the native messaging API: registration for discovery by Firefox.
- Although not listed here, I'm mentioning for completeness that there are also MSIX versions of Firefox. I expect no issues with step 1 because the global registry should be readable, but I imagine step 2 to be problematic: the launch mechanism needs to run an external application, preferably outside the container of Firefox.
A similar issue here is observed on Ubuntu, where Firefox runs within a container (Snap / flatpak - bug 1661935). In that case, a component running outside the container (a so-called portal) was developed, with Firefox being updated to communicate to that portal. The portal handles lookup of the registration and the launch, and Firefox and the application then communicate "directly" via the standard stdin/stdout pipes.
I'm not sufficiently familiar with MSIX to tell what should happen here. Ideally we should adhere to the platform conventions, and if there are none, use mechanisms that stand a chance of being adopted outside of Firefox.
@Graham
Is it feasible to have an external application that creates the registry key and files necessary to allow Firefox to locate your application? If not, why is it not feasible?
|
|
Reporter | |
Comment 8•1 year ago
|
||
Is it feasible to have an external application that creates the registry key and files necessary to allow Firefox to locate your application? If not, why is it not feasible?
The end goal is:
- End user visits Windows Store.
- End user buys / downloads application on the Windows Store that happens to contain a native extension, but end user doesn't know or care about that.
- Native application enjoys access to all bleeding edge functionality that Microsoft wants to sell customers, right now that's WinUI3, in an MSIX sandbox.
- End user grants permission for native application to be visible to webpage.
- End user uses native application.
So any external application breaks "end user visits Windows Store".
It looks to me that the registry keys are a non starter and need to be deprecated. I've gone digging for the ways MSIX offers app discovery, one of them is by file extension. Firefox could ask Windows to open a suitably named manifest file in the browser extension, and the native app kicks in and does the stdin/stdout magic as normal. Another option is for native application to associate with a MIME type.
Do you have access to an MSIX guru who can go through the options? My exposure to MSIX is trying to get it to work and failing.
|
|
||
Comment 9•1 year ago
|
||
(In reply to Rob Wu [:robwu] from comment #7)
- Although not listed here, I'm mentioning for completeness that there are also MSIX versions of Firefox. I expect no issues with step 1 because the global registry should be readable, but I imagine step 2 to be problematic: the launch mechanism needs to run an external application, preferably outside the container of Firefox.
Surprisingly this is not an issue for MSIX packages that are not deployed for Windows S Mode (which Firefox is not).
In MSIX only the registry and %UserProfile%\AppData are virtualized, details here. Everything else the user has permission to access is accessible to MSIX applications without virtualization.
|
||
Comment 10•2 days ago
|
||
Since this has been changed to an enhancement I will open it and maybe someone can pick this one later on.
Description
•