1955255 - [flatpak] [snap] Implement xdg-native-messaging-proxy frontend

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Jan Horak [:jhorak]]

Since the webextension API has not been accepted to the xdg desktop portals, we've come with xdg-native-messaging-proxy service which simplifies the native messaging api calls over DBUS. it also narrow usage of the webextension API only to application which has the access to the org.freedesktop.NativeMessagingProxy service (unlike having WebExtension API in the xdg desktop portal).

The org.freedesktop.NativeMessagingProxy service generally provides three dbus methods:

• GetManifest(messaging_host_name, mode) -> returns json string of the found manifest on the host system
• Start(messaging_host_name, extension_or_origin, mode) -> start the web extension process and returns its stdin/stdout/stderr pipes and session handle
• Close(handle) -> unregisters and terminates the process.

The Firefox side implementation is simplified with the AsyncDBus promises (https://searchfox.org/mozilla-central/source/widget/gtk/AsyncDBus.h).

Code and specification of the xdg-native-messaging-proxy (also with its purpose reasoning)
https://github.com/swick/xdg-native-messaging-proxy

Comment 1

[Jan Horak [:jhorak]]

Attachment: Bug 1955255 Allow passing returned GUnixFDList to the DBusCallFDListPromise; r=emilio

We want to use the returned fds when g_dbus_proxy_call_with_unix_fd_list_finish is called.
This change passes the argument as a std::pair to the fulfillment handler.

Comment 2

[Jan Horak [:jhorak]]

Attachment: Bug 1955255 Allow passing returned GUnixFDList to the DBusCallFDListPromise; r=emilio

We want to use the returned fds when g_dbus_proxy_call_with_unix_fd_list_finish is called.
This change passes the argument as a std::pair to the fulfillment handler.

Comment 3

[Jan Horak [:jhorak]]

Attachment: Bug 1955255 Implement native messaging using xdg-native-messaging-proxy; r=robwu

Comment 4

[Rob Wu [:robwu]]

For visibility, the original Firefox side implementation of native messaging through xdg desktop portal is in bug 1661935. Before the patch landed in Firefox, Ubuntu has shipped it for a number of releases as a custom patch on top of their Firefox flavor.

Even now, that implementation is disabled by default (https://searchfox.org/mozilla-central/rev/dd8b5213e4e7760b5fe5743fbc313398b85f8a14/modules/libpref/init/StaticPrefList.yaml#18350-18357) with a custom patch to toggle the preference on Snap builds for Ubuntu: https://github.com/canonical/firefox-snap/blob/032405220c879daa9454a7e7aff821ec3009533c/patches/native-messaging-portal.patch

The feature was intentionally off by default in Firefox to allow stabilization of the feature, including potentially changing parts of the protocol. The proposed patches here do that.

Changing the implementation can potentially prevent Firefox snap on older Ubuntu releases from using the NativeMessaging feature, unless the new service component is also shipped.

Are the snap/ubuntu maintainers already aware of this proposal?

Comment 5

[Jan Horak [:jhorak]]

We've discussed it with Marco Trevisan from Canonical during last Fosdem in person together with Sebastian Wick. We've somehow agreed to use non-portal dbus service for Native messaging API which later Sebastian implemented.

AFAIK I'm afraid that the current xdg desktop portal WebExtension API wont make it into the upstream.

You're right this would break the Ubuntu ATM unless they're willing to ship the org.freedesktop.NativeMessagingProxy. To avoid these problems, would you rather have it as separate implementation next to WebExtensions and later possibly remove the org.freedesktop.portal.Desktop.WebExtensions implementation?

Comment 6

[:gerard-majax]

Is this what https://github.com/flatpak/xdg-desktop-portal/pull/1537#issuecomment-2747856356 is about ? What does it means for https://bugzilla.mozilla.org/show_bug.cgi?id=1928096 ?

Comment 7

[seb128]

You're right this would break the Ubuntu ATM unless they're willing to ship the org.freedesktop.NativeMessagingProxy

Replying as part of the Ubuntu Desktop team. The issue isn't whether we are willing to ship it or not, it is that the patch from https://github.com/flatpak/xdg-desktop-portal/pull/705 is currently included in the xdg-desktop-portal package of Ubuntu 24.04 LTS. Assuming that we would be able to get the new service rolled out in a stable update (which by itself would be challenging since it is clearly neither minimal nor bugfix focused) we would still be in a situation where we don't have a technical mean to ensure that the firefox (snap) and portal (deb) are on compatible versions/upgraded together.

Comment 8

[Rob Wu [:robwu]]

(In reply to Jan Horak [:jhorak] from comment #5)

We've discussed it with Marco Trevisan from Canonical during last Fosdem in person together with Sebastian Wick. We've somehow agreed to use non-portal dbus service for Native messaging API which later Sebastian implemented.

The dependent project (https://github.com/swick/xdg-native-messaging-proxy) currently consists of 1 commit in a personal repository. It is unclear whether this has gone through any (code) reviews, and where the long-term responsibility of maintenance is. And although it is promising for the approach to have been discussed with Canonical people, it is necessary for them to commit to integrating and shipping it too, or else this Firefox-side implementation would not offer any value to end users.

You're right this would break the Ubuntu ATM unless they're willing to ship the org.freedesktop.NativeMessagingProxy. To avoid these problems, would you rather have it as separate implementation next to WebExtensions and later possibly remove the org.freedesktop.portal.Desktop.WebExtensions implementation?

This is a question for Canonical. As they distribute Firefox, they are also in the position of distributing additional dependencies if needed. Alternatively, they can also maintain a separate patch (like they have done for years) to integrate the patched-portal implementation.

Provided that the consensus is on the proposal here, the least risky way of rolling this out would then be as follows:

1. Land the Firefox side of the new "proxy" (portal? Can we use that name?), behind a preference.
2. Enable the preference, Nightly-only. Maybe for two releases or so - this step can only start when the new dependency is installed alongside the Firefox package.
3. Enable the preference for all release channels.
4. After a few releases without regressions, remove the obsolete parts of the previous implementation.

Currently, a risk to refactoring is that there is no end-to-end test coverage that verifies interoperability across all dependencies. Bug 1928096 aims to fill a gap on the Firefox side, but that test would likely run with a specific Ubuntu image. To avoid regressions, it would be necessary to run tests with Ubuntu (older LTS and newer).

Side note: I have already spent dozens of hours on reviewing both the Firefox and the portal side of this functionality. It would be really nice if we were all aligned on the direction, and then execute on that to avoid more delays and wasted time. If needed we can set up a meeting to get there.

(In reply to seb128 from comment #7)

You're right this would break the Ubuntu ATM unless they're willing to ship the org.freedesktop.NativeMessagingProxy

Assuming that we would be able to get the new service rolled out in a stable update (which by itself would be challenging since it is clearly neither minimal nor bugfix focused) we would still be in a situation where we don't have a technical mean to ensure that the firefox (snap) and portal (deb) are on compatible versions/upgraded together.

What would be a realistic timeline for Ubuntu to integrate a new dependency?

Comment 9

[sebastian]

Hey Rob!

The dependent project (https://github.com/swick/xdg-native-messaging-proxy) currently consists of 1 commit in a personal repository. It is unclear whether this has gone through any (code) reviews, and where the long-term responsibility of maintenance is.

We will ship this in RHEL 10. It didn't undergo code separate review unfortunately, but it's based on existing xdg-desktop-portal code and code from the PR. It also has more extensive tests already.

In any case, this should not be worse than the portal implementation.

Side note: I have already spent dozens of hours on reviewing both the Firefox and the portal side of this functionality. It would be really nice if we were all aligned on the direction, and then execute on that to avoid more delays and wasted time. If needed we can set up a meeting to get there.

I'm also a bit frustrated. The security concerns have not been taken seriously or not been understood entirely, which made people move into a direction with no path forward. I would have loved to have a meeting about this one, but getting a hold of some of the people involved turned out to be a struggle. I will happily join a meeting if we manage to get the important people on board.

Comment 12

[Jan Grulich]

Hi Rob Wu,

I've sent an email to the Flatpak mailing list about making the xdg-native-messaging-proxy the official solution. It would be great to also get a feedback from the Firefox side. Firefox is currently in an unfortunate situation, where the original webextensions portal support was merged, even though it has never been anything official and was only shipped downstream in Ubuntu. I share the concern that you don't want to break the Ubuntu use-case, on the other hand since it was only a downstream thing I would argue Ubuntu can also support the Firefox side downstream, but I believe we can figure out a solution that works for both the upstream and Ubuntu. Would you mind adding your opinion on the matter there? The goal here is to finally agree on a solution and unblock the review from Jan Horak.

The email is here: https://lists.freedesktop.org/archives/flatpak/2025-April/002381.html

Comment 13

[Rob Wu [:robwu]]

The email at https://lists.freedesktop.org/archives/flatpak/2025-April/002382.html is missing a reference to this bug, and consequently those answering there may not have the full context, including the comments that I have posted before on the topic (comment 4 and comment 8 in particular).

For example, the question in the first reply written by Georges,

What I'd like to know is if Firefox folks would be open to changing their
patches slightly to it.

is directly answered by this fragment of comment 4 that I wrote above:

Even now, that implementation is disabled by default (https://searchfox.org/mozilla-central/rev/dd8b5213e4e7760b5fe5743fbc313398b85f8a14/modules/libpref/init/StaticPrefList.yaml#18350-18357) with a custom patch to toggle the preference on Snap builds for Ubuntu: https://github.com/canonical/firefox-snap/blob/032405220c879daa9454a7e7aff821ec3009533c/patches/native-messaging-portal.patch

The feature was intentionally off by default in Firefox to allow stabilization of the feature, including potentially changing parts of the protocol.

Comment 14

[:gerard-majax]

Any news ? I cant see any publicly facing progress on that matter. Anything we could help with? It's really frustrating, we have been able to land support to remove the need for Snap and Flatpak to apply local build patches in bug 1661935 but this was still under a pref until we could get bug 1928096. However, progresses on that testing have been halted until the current situation is solved.

Comment 15

[Jan Grulich]

(In reply to :gerard-majax from comment #14)

Any news ? I cant see any publicly facing progress on that matter. Anything we could help with? It's really frustrating, we have been able to land support to remove the need for Snap and Flatpak to apply local build patches in bug 1661935 but this was still under a pref until we could get bug 1928096. However, progresses on that testing have been halted until the current situation is solved.

There is no progress on this, we sill didn't move the xdg-native-messaging-proxy under the Flatpak project to make it official. I was hoping Rob Wu [:robwu] to reply to the Flatpak email thread to give a clearance from Firefox side. I know there are concerns about breaking it for Ubuntu, but I think this can be kept supported on the Firefox side by having both implementations there, just sharing some parts of the code. Anyway, first step is still to make it official and then we can shift focus to implementation in Firefox.

Comment 16

[Rob Wu [:robwu]]

There is no progress on this, we sill didn't move the xdg-native-messaging-proxy under the Flatpak project to make it official. I was hoping Rob Wu [:robwu] to reply to the Flatpak email thread to give a clearance from Firefox side.

On the Firefox side I'm supportive of the necessary changes to make this available to users, ideally in well-supported dependencies.
In comment 13 above I linked the relevant email thread, and also my previous comments where I had already expressed support for changing the Firefox-side implementation as needed.

The most recent reply on the thread (https://lists.freedesktop.org/archives/flatpak/2025-April/002386.html) already quotes my reply, including the (correct) interpretation "So my understanding is there can be changes to the Firefox implementation, but there is a concern about Ubuntu".

My expectations on the next steps are as follows:

• https://github.com/swick/xdg-native-messaging-proxy to be moved to a more official place to ensure long-term maintenance and support.
• Ubuntu representatives to agree with the proposed packages, including a position on LTS versions of Ubuntu. If they deem it to be unacceptable to include a new dependency, the lack of availability could be addressed by continuing the current ("old") implementation in Firefox until the relevant systems enter the EOL stage.
• Prepare patches and get sign-off on the new implementation in Firefox (I can review and sign off).

Comment 17

[Rob Wu [:robwu]]

For the record, the repository now moved to the flatpak org, at https://github.com/flatpak/xdg-native-messaging-proxy

The original mailing list thread got disconnected somehow, but for those interested in the mailing list, here are the current threads:

• https://lists.freedesktop.org/archives/flatpak/2025-April/002386.html
• https://lists.freedesktop.org/archives/flatpak/2025-June/002390.html

I also mentioned this development in the xdg-desktop-portal PR at https://github.com/flatpak/xdg-desktop-portal/pull/1537#issuecomment-3013428674

I'm planning to review the patch here sometime in the next few weeks.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.