1738441 - Firefox Flatpak does not integrate with the Plasma browser integration package

Status: RESOLVED DUPLICATE of bug 1621763

(WebExtensions :: Untriaged, defect)

Description

[Oshan Wisumperuma]

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

Steps to reproduce:

1. install firefox as a flathub package
2. install plasma integration extension
3. install plasma-browser-integration package on the host os

Actual results:

extension notifies that failed to connect the native host.
slimier issue is reported for the chromium flathub package.
https://github.com/flathub/org.chromium.Chromium/issues/34

Expected results:

it should integrate with the plasma and should provide features listed over here.
https://community.kde.org/Plasma/Browser_Integration

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I’m from QA and unfortunately I cannot proceed with the reproduction steps of the issue as after I installed one of the pre-requisites of this issue (the Plasma shell), the desktop is completely black (only the cursor is visible and no interaction is possible).

I’m running Ubuntu 16.04 LTS.

Comment 3

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

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

Took me a while but I finally took a look into this, and in particular:

if there was an upstream flatpak issue for a long term solution that fits in the flatpak sandbox and architecture (basically an xdg-desktop-portal, as in other cases where a sandboxed application needs to communicate with something external to that sandboxed envrionment)

• flatpak/xdg-desktop-portal#655 - NativeMessaging portal for sandboxed browsers

and if there was a reasonable way for a user to workaround the issue while still using a flatpak-packaged Firefox build

• unfortunately flatpak override org.mozilla.firefox --filesystem=/usr/lib/mozilla --filesystem=<path-to-native-app-binary> --filesystem=<path-to-other-dirs-native-app-binary-depends-on> isn't enough to workaround the issue as a user
• it seems it does not because /usr/lib or /usr/bin are already mapped by flatpak that flatpak override can't expose the ones where the native app is in the filesystem as seen from outside the sandboxed environment (as it can also be confirmed manually by entering in the org.mozilla.firefox sandboxed environment with a shell using flatpak run --command=/bin/sh --filesystem=<dirs-to-give-access-to> org.mozilla.firefox)
• it seems still possible to workaround it using the flatpak overrides if the native app manifest and binary (and dependencies of that binary) are all relocated in a path that can be exposed using flatpak overrides, but it doesn't seem a great workaround, especially for less experienced users (and it would need to be adapted case by case based on the particular native app)

Technically this issue is actually a duplicate of Bug 1621763, filed in "Core::Widget:Gtk" bugzilla component and blocking the flatpak tracking meta Bug 1278719.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Mike,
could you help us to make sure this WebExtensions issue specific to flatpak packages are under the radar of the right people?
In particular we'd like:

• to be sure we are tracking this on bugzilla and link it appropriately to meta / tracking issue related to the flatpak bugzilla
• to confirm which would be the long term solution to support this use case that fits in the flatpak architecture (e.g. flatpak/xdg-desktop-portal#655 that I linked in comment 4 looks like one long term solution being discussed upstream)
• to evaluate other shorter term solution to allow flatpak packaged Firefox to support WebExtensions NativeMessaging feature (especially if the timing for the flatpak package to become the default one in some distribution if shorter than the time needed to be able to aim for a more complete and long term solution like flatpak/xdg-desktop-portal#655)

Related to the first point, I did notice that Bug 1621763 and this issue are duplicates in practice, just filed in two different bugzilla components, should we close this one in favor of Bug 1621763?

Thanks in advance for your help!