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 Port webextension flatpak portal implementation to 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.