Open Bug 1661935 Opened 4 years ago Updated 12 days ago

Support NativeMessaging in Snap

Categories

(WebExtensions :: General, defect, P3)

80 Branch
Desktop
Linux
defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: eduardo.rojasr, Assigned: gerard-majax)

References

(Depends on 2 open bugs, Blocks 7 open bugs)

Details

(Whiteboard: [addons-jira])

Attachments

(6 files, 3 obsolete files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Steps to reproduce:

Use the Firefox Snap build from Ubuntu Snap Store (Ubuntu software).

Install "chrome-gnome-shell" package.

Install Firefox GNOME Shell integration.

Go to "extensions.gnome.org" and choose any extension.

Actual results:

Actual results:

An error report shows that says the native host connector cannot be detected.

There is no option to install the GNOME extension.

Expected results:

Expected results:

I should be able to install the chosen GNOME extension directly from the website and manage it afterwards.

The behavior is correct on the current RPM/DEB builds.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

This bug is also being tracked at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1741074

Ubuntu 21.10 ships the snap version of Firefox by default, (instead of the APT version), so we can expect more users to experience this bug.

Flatpak counterpart: bug 1621763.

See Also: → 1621763

S2 (Serious) Major functionality/product severely impaired and a satisfactory workaround does not exist

Severity: -- → S2

Proposal for a new NativeMessaging portal to address this issue: https://github.com/flatpak/xdg-desktop-portal/issues/655.

See Also: → 1734371
See Also: 1738488
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Summary: Snap: cannot install/manage extensions from extensions.gnome.org → Snap does not support NativeMessaging

This bug report is getting triaged, I'm glad. I'll add that Ubuntu 22.04 LTS is planning on removing Firefox from the APT repositories altogether and to only provide the snap version of Firefox, which is Ubuntu's default browser, so this bug is going to be experienced by a large fraction of the Ubuntu userbase at some point.

Assignee: nobody → olivier
Attachment #9267325 - Attachment description: WIP: Bug 1661935 - [WIP] Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux
Status: NEW → ASSIGNED
Attachment #9267325 - Attachment description: WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux

Chiming in as a maintainer of an extension (ff2mpv) that uses native messaging: users have already reported challenges getting the extension to function correctly with the snap-ified Firefox distribution in the upcoming Ubuntu LTS release.

Downstream tracking: https://github.com/woodruffw/ff2mpv/issues/80

Attachment #9267325 - Attachment description: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux
Blocks: 1462888
Attachment #9267325 - Attachment description: WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux
Blocks: snap-sandbox
Attachment #9267325 - Attachment description: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux
Attachment #9267325 - Attachment description: WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux
Depends on: 1788091

I'm entering a comment here because I've not seen a tracker for the snap releases having native messaging enabled.

I've been using native messaging in FireFox to integrate with KeePassXC for several weeks now, through several FireFox beta releases (currently "beta" snap channel version 105.0b5-1). It is working as expected.

The only issue I noticed so far is each FireFox Profile needs its own separate connector to the KeePassXC database. This makes sense, but might warrant some documentation, somewhere.

(In reply to William Woodruff from comment #10)

Chiming in as a maintainer of an extension (ff2mpv) that uses native messaging: users have already reported challenges getting the extension to function correctly with the snap-ified Firefox distribution in the upcoming Ubuntu LTS release.

Downstream tracking: https://github.com/woodruffw/ff2mpv/issues/80

Following up on this: I'm able to confirm that the extension I maintain works correctly on the "beta" channel of the Firefox snap.

However, to get it working, I had to run a manual flatpak command on the terminal:

flatpak permission-set webextensions ff2mpv snap.firefox yes

Is this documented somewhere? I had to dig through others' bug reports to figure out that this is what I needed, and I can imagine that a lot of other native extension users (and developers) are in a similar position.

As explained in the ff2mpv issue, desktop shells (such as GNOME Shell) and portal frontends (such as xdg-desktop-portal-gtk and xdg-desktop-portal-kde) should display a modal prompt the first time an extension requires this permission, and so you wouldn't need to use the flatpak command to make this choice "by hand". However minimal window managers without portal frontends (e.g. i3) are unlikely to implement that prompt, and the answer will default to "no".

Whiteboard: [addons-jira]

The snap now supports native messaging through the use of the WebExtensions portal, which is available as a distro-patch in Ubuntu 22.04 and 22.10.

I am not closing this bug yet, because even though the patch has been cherry-picked in the snap, it hasn't landed in the tree yet.

Olivier, are you still able to actively work on that ?

Flags: needinfo?(olivier)
Duplicate of this bug: 1462888
Severity: S2 → N/A
Type: defect → enhancement
Summary: Snap does not support NativeMessaging → Support NativeMessaging in Snap
Depends on: 1836718
Attachment #9267325 - Attachment description: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux
See Also: → 1843341

Olivier has left Canonical and the patch has been taken over by :bandali. I'm therefore re-assigning the bug for clarity.

Also, considering that the majority of the work is in extension code, I'm moving the bug to WebExtensions.

Assignee: olivier → bandali
Component: Widget: Gtk → General
Flags: needinfo?(olivier)
Product: Core → WebExtensions
See Also: → 1847377
Depends on: 1847377, 1843341
See Also: 1843341, 1847377

(In reply to David D Lowe from comment #3)

This bug is also being tracked at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1741074

Ubuntu 21.10 ships the snap version of Firefox by default, (instead of the APT version), so we can expect more users to experience this bug.

I have same problem. Few days ago i have installed Kubuntu 23.10 "Mantic Minotaur" replacing Linux Mint 21.2 "Victoria". the extension doesn't work as well (Including KDE Browser Integration, a Download Manager (Persepolis Download Manager Integration, Aria-NG Integration)). I have grant Permission but nothing happen lol.

KDE Plasma Integration on Firefox 120.

See Also: → 1876447
Severity: N/A → S2
Priority: -- → P1
Severity: S2 → N/A
Type: enhancement → defect
Priority: P1 → P3
Severity: N/A → S3
Blocks: 1903306
Blocks: 1903309
Blocks: 1903338
See Also: → 1903246

(In reply to david from comment #22)

Same probleme here with ubuntu 24.04.1, and firefox snap.

"Failed to connect to the native host."

Hello, could you please provide more information about this?

  • Is this a fresh Ubuntu 24.04 LTS installation? Or did you upgrade from an existing Ubuntu release to this one? (If yes, from which version?)
  • Please open a terminal, run the following commands, and provide the output here:
apt list --installed | grep xdg-desktop-portal
apt-cache policy xdg-desktop-portal
snap version
  • Which Firefox version are you using?
  • Which Firefox add-on are you trying to use here? And did you add a manifest for it under the ~/.mozilla/native-messaging-hosts/ directory?
  • Are there any more error or warning messages in the logs beyond the one line you provided?

Thanks.

Flags: needinfo?(david)

(In reply to Amin Bandali [:bandali] from comment #23)

(In reply to david from comment #22)

Same probleme here with ubuntu 24.04.1, and firefox snap.

"Failed to connect to the native host."

Hello, could you please provide more information about this?

  • Is this a fresh Ubuntu 24.04 LTS installation? Or did you upgrade from an existing Ubuntu release to this one? (If yes, from which version?)
  • Please open a terminal, run the following commands, and provide the output here:
apt list --installed | grep xdg-desktop-portal
apt-cache policy xdg-desktop-portal
snap version
  • Which Firefox version are you using?
  • Which Firefox add-on are you trying to use here? And did you add a manifest for it under the ~/.mozilla/native-messaging-hosts/ directory?
  • Are there any more error or warning messages in the logs beyond the one line you provided?

Thanks.

Hi,

  • This is not a fresh ubuntu install (its a upgraded version from ubuntu 22.04 LTS), BUT, I'm using a fresh account to test (new user, new /home).
  • This is the output of the commands:

apt list --installed | grep xdg-desktop-portal

xdg-desktop-portal-gtk/noble,now 1.15.1-1build2 amd64 [installed,automatic]
xdg-desktop-portal-kde/noble,now 5.27.11-0ubuntu3 amd64 [installed,automatic]
xdg-desktop-portal/noble-updates,now 1.18.4-1ubuntu2 amd64 [installed,automatic]

apt-cache policy xdg-desktop-portal

xdg-desktop-portal:
  Installed: 1.18.4-1ubuntu2
  Candidate: 1.18.4-1ubuntu2
  Version table:
 *** 1.18.4-1ubuntu2 500
        500 http://fr.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.18.3-1ubuntu1 500
        500 http://fr.archive.ubuntu.com/ubuntu noble/main amd64 Packages

snap version

snap    2.63.1+24.04
snapd   2.63.1+24.04
series  16
ubuntu  24.04
kernel  6.8.0-41-generic
  • Firefox version is 130.0 (64-bit)

  • The firefox addon I'm trying to use is: https://addons.mozilla.org/en-US/firefox/addon/plasma-integration/. I did not add a manifest for it under ~/.mozilla/native-messaging-hosts/ directory.

  • On the extension console, I can see the messages:

    Invalid url undefined action_popup.js:86:33
    Failed to check for whether media controls are blocked NO_ORIGINS action_popup.js:279:17

and in about:debugging#/runtime/this-firefox i see:

Warning details
Reading manifest: Warning processing key: An unexpected property was found in the WebExtension manifest.

if I try to reload the addon I get:

Host disconnected An unexpected error occurred extension.js:204:17
Not auto-restarting host as we haven't received any message from it before. Check that it's working/installed correctly extension.js:226:21
Background event page was not terminated on idle because a DevTools toolbox is attached to the extension. _generated_background_page.html
Flags: needinfo?(david)
Attachment #9267325 - Attachment description: WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux → WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux r=robwu
Attachment #9267325 - Attachment description: WIP: Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux r=robwu → Bug 1661935 - Integration with a new WebExtensions XDG desktop portal for native messaging on Linux r=robwu
$ pip install --no-use-pep517 python-dbusmock==0.32.2
Collecting python-dbusmock==0.32.2
  Using cached python-dbusmock-0.32.2.tar.gz (104 kB)
ERROR: Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta in pyproject.toml

Kagami in https://bugzilla.mozilla.org/show_bug.cgi?id=1868690#c10 you mentionned --no-use-pep517 as temporary? Can we remove it?

Flags: needinfo?(krosylight)
(venv-python-dbusmock) alex@portable-alex:~/tmp/mozillasupport$ pip install --upgrade setuptools==70.0.0 wheel==0.43.0
Collecting setuptools==70.0.0
  Using cached setuptools-70.0.0-py3-none-any.whl.metadata (5.9 kB)
Collecting wheel==0.43.0
  Using cached wheel-0.43.0-py3-none-any.whl.metadata (2.2 kB)
Using cached setuptools-70.0.0-py3-none-any.whl (863 kB)
Using cached wheel-0.43.0-py3-none-any.whl (65 kB)
Installing collected packages: wheel, setuptools
  Attempting uninstall: wheel
    Found existing installation: wheel 0.44.0
    Uninstalling wheel-0.44.0:
      Successfully uninstalled wheel-0.44.0
  Attempting uninstall: setuptools
    Found existing installation: setuptools 75.2.0
    Uninstalling setuptools-75.2.0:
      Successfully uninstalled setuptools-75.2.0
Successfully installed setuptools-70.0.0 wheel-0.43.0
(venv-python-dbusmock) alex@portable-alex:~/tmp/mozillasupport$ pip install python-dbusmock==0.32.2
Collecting python-dbusmock==0.32.2
  Using cached python-dbusmock-0.32.2.tar.gz (104 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: dbus-python in ./venv-python-dbusmock/lib/python3.12/site-packages (from python-dbusmock==0.32.2) (1.3.2)
Building wheels for collected packages: python-dbusmock
  Building wheel for python-dbusmock (pyproject.toml) ... done
  Created wheel for python-dbusmock: filename=python_dbusmock-0.32.2-py3-none-any.whl size=73663 sha256=838a8a57b4240b19003b00188a1e63c90f6b4f5f19d0ca8e7c0803ffec0dcc95
  Stored in directory: /home/alex/.cache/pip/wheels/fd/95/73/9cc598f34c15d81a7a4b400328064875b72d637c10ab236ae7
Successfully built python-dbusmock
Installing collected packages: python-dbusmock
Successfully installed python-dbusmock-0.32.2

Not sure why it fails on CI: https://treeherder.mozilla.org/logviewer?job_id=478870258&repo=try

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

Kagami in https://bugzilla.mozilla.org/show_bug.cgi?id=1868690#c10 you mentionned --no-use-pep517 as temporary? Can we remove it?

That would require https://bugzilla.mozilla.org/show_bug.cgi?id=1868690#c3 option 2. I don't know whether anyone did it, maybe ahal knows.

Flags: needinfo?(krosylight) → needinfo?(ahal)

No work has been done or planned here afaik,

But yeah, if I'm understanding the situation, --no-use-pep517 is just a bandaid to allow our outdated infrastructure to chug along a little while longer. But at some point someone is going to have to do the actual work of updating our tooling to modern Python standards.

Flags: needinfo?(ahal)

(In reply to Andrew Halberstadt [:ahal] from comment #29)

No work has been done or planned here afaik,

But yeah, if I'm understanding the situation, --no-use-pep517 is just a bandaid to allow our outdated infrastructure to chug along a little while longer. But at some point someone is going to have to do the actual work of updating our tooling to modern Python standards.

Thanks. Does it means we cannot install this package until that work is done?

I think so.. I don't remember why we added --no-use-pep517 in the first place, it looks like it might have been to improve performance? If so we could alternatively back that patch out.

Wasn't --no-use-pep517 to skip building wheel? It still builds wheel here and then fails, so not sure why the flag is relevant here.

So, how should such a package installed ?

Flags: needinfo?(krosylight)
Flags: needinfo?(ahal)

All I can say is that pip install --timeout 120 --no-index --find-links https://pypi.pub.build.mozilla.org/pub/ python-dbusmock==0.32.2 (the command from the CI log in comment #27) fails on my local machine too with the same error. Not sure why it behaves differently from pip install python-dbusmock==0.32.2.

Flags: needinfo?(krosylight)

interesting, it also fails for me, that's not something i would have expected

When it works i can see:

  Using cached setuptools-75.2.0-py3-none-any.whl (1.2 MB)
  Using cached setuptools_scm-8.1.0-py3-none-any.whl (43 kB)
  Using cached packaging-24.1-py3-none-any.whl (53 kB)
  Installing collected packages: setuptools, packaging, setuptools-scm
  Successfully installed packaging-24.1 setuptools-75.2.0 setuptools-scm-8.1.0

When it does not we install other versions:

  Looking in links: https://pypi.pub.build.mozilla.org/pub/
  Collecting setuptools>=45
    Using cached https://pypi.pub.build.mozilla.org/pub/setuptools-69.0.3-py3-none-any.whl (819 kB)
  Collecting setuptools-scm
    Using cached https://pypi.pub.build.mozilla.org/pub/setuptools_scm-3.3.3-py2.py3-none-any.whl (23 kB)
  Installing collected packages: setuptools-scm, setuptools
  Successfully installed setuptools-69.0.3 setuptools-scm-3.3.3
  Installing build dependencies: finished with status 'done'

So maybe the setuptools version we have on our Pypi mirror is not recent enough? Or it's setuptools-scm?

Depends on: 1923904

Making a local dumb pypi mirror i could confirm:

  • unable to install with setuptools-69.0.3 setuptools-scm-3.3.3
  • able to install with packaging-23.1 setuptools-75.2.0 setuptools-scm-8.1.0

Maybe we could have the wheel instead of the tar of dbusmock a wheel on our pypi mirror?

Flags: needinfo?(ahal)
Assignee: bandali → lissyx+mozillians
Attached file GitHub Pull Request (obsolete) —

Upstream removal of the patch PR against nightly

Duplicate of this bug: 1621763
Attached file GitHub Pull Request

Correct PR to remove the patch on nightly branch

Attachment #9433859 - Attachment is obsolete: true
Depends on: 1928084
Blocks: 1928096
Pushed by alissy@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/594beeb5e424 Integration with a new WebExtensions XDG desktop portal for native messaging on Linux r=emilio,robwu,rpl,Gijs,andi,mach-reviewers https://hg.mozilla.org/integration/autoland/rev/7b10b4e274db Native Messaging WebExtension documentation r=robwu,rpl https://hg.mozilla.org/integration/autoland/rev/620790051502 Native Messaging WebExtensions portal tests r=robwu,ahal

Backed out for causing xpcshell failures @@CycleCollectedJSContext.

Flags: needinfo?(lissyx+mozillians)
Backout by agoloman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/59ce3da9e504 Backed out 3 changesets for causing xpc failures @test_subprocess.js.
Flags: needinfo?(lissyx+mozillians)

(In reply to Pulsebot from comment #46)

Backout by agoloman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/59ce3da9e504
Backed out 3 changesets for causing xpc failures @test_subprocess.js.

So it looks like we are facing some bad case of a race condition here. We create running spawning a process and then we connectRunning with its FDs and get a second proc process. There running.stdout is id: 1 and had fd: 16 when proc.stdin is id: 5 with fd: 16 which seems to be consistent with the expected behavior of those pipes. It means we have two InputPipe that shares the same FD. Upon creation they fillBuffer https://searchfox.org/mozilla-central/rev/b1cd7e191ac57f8dfe31806be2539e51843c03eb/toolkit/modules/subprocess/subprocess_common.sys.mjs#295. So both enqueues a read  call. Somehow the pollfd.revents https://searchfox.org/mozilla-central/rev/b1cd7e191ac57f8dfe31806be2539e51843c03eb/toolkit/modules/subprocess/subprocess_unix.worker.js#569 turns != 0for the InputPipe of id:5 before the id:1 and so we trigger reading the content of the pipe, which is then not available anymore to id:1.

See Also: → 1930119
Attachment #9437056 - Attachment description: WIP: Bug 1661935 - Handle Pipe vs connectRunning → Bug 1661935 - connectRunning should dup() FDs r?mossop!
Attachment #9437156 - Attachment description: WIP: Bug 1661935 - Properly close process from connectRunning() → Bug 1661935 - Properly close process from connectRunning() r?mossop!
Attachment #9437056 - Attachment description: Bug 1661935 - connectRunning should dup() FDs r?mossop! → Bug 1661935 - connectRunning test should use FDs that were dup()'d r?mossop!
Attachment #9437056 - Attachment description: Bug 1661935 - connectRunning test should use FDs that were dup()'d r?mossop! → Bug 1661935 - Introduce ManagedProcess and connectRunning()
Attachment #9437156 - Attachment is obsolete: true
Attachment #9437056 - Attachment is obsolete: true
Blocks: 1621763
No longer duplicate of this bug: 1621763
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: