Companion app cannot be found when using Flatpak builds of Firefox

[zareami10]

Having Firefox installed vie Flathub, and vdhcoapp (1.6.1-1) via AUR in Arch, I still get the message Checking companion app returned: No such native application net.downloadhelper.coapp.

I'm not completely sure how things work, but maybe it's due to the limited filesystem permission?

[mi-g]

As far as i understand, flat installs create a sandbox so that the installed app (here Firefox) cannot access most assets in the machine (here the coapp files). Maybe there is a workaround to make the coapp viewable from Firefox but it must be a thoughful action from the user because it will break the sandbox mechanism. Anyway, i do not consider this an issue from the VDH companion app.

[teohhanhui]

Anyway, i do not consider this an issue from the VDH companion app.

It's something that needs to be supported. Many distros are starting to ship Flatpak version of Firefox by default.

Or at the very least, there needs to be instructions for a workaround to get it working... The users can't be expected to figure that out on their own...

[JordanL2]

It would help if it was possible to specify the path to the executable of the companion app. This way the app could be installed from the tarball to /opt or somewhere in the user's home, and grant access to that path to the Firefox flatpak.

@mi-g any chance this option could be added?

[JordanL2]

Looking into it a bit more, possibly not, as the native app path needs to be specified in its manifest. (EDIT: I suppose you could move the app installation path to /opt for all linux users, doesn't seem great though.) https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

This looks like a problem Mozilla has to solve, and indeed there is an open issue for it: https://bugzilla.mozilla.org/show_bug.cgi?id=1621763

User "wsha.code" in the above thread posted a potential (hacky) workaround for this problem.

[posita]

Work-around reproduced here (emphasis added):

[H]ere is an insecure workaround you can use if you don't care too much about keeping Firefox sandboxed:

1. Copy the native application's app manifest file from /usr/lib64/mozilla/native-messaging-hosts/.json to ~/.var/app/org.mozilla.org/.mozilla/native-messaging-hosts/.json
2. Create a new file in ~/.var/app/org.mozilla.org/.mozilla/native-messaging-hosts with name like .sh and mark it as executable. Make its first line be #!/bin/bash and its second be flatpak-spawn --host <path> "$@" where is the "path" entry in the app manifest json file that was copied.
3. Edit ~/.var/app/org.mozilla.org/.mozilla/native-messaging-hosts/<app-id>.json to change the "path" entry to be the absolute path to the .sh file created in step #2.
4. Start the Firefox flatpak with flatpak run --talk-name=org.freedesktop.Flatpak. If you want, you can run flatpak override --talk-name=org.freedesktop.Flatpak org.mozilla.firefox to make this a default permission for the flatpak so you don't need to specify it each time the flatpak is run.

This workaround is not good for sandboxing because it allows Firefox to call flatpak-spawn to run arbitrary commands on the host. Obviously, a better solution would be preferred. If you are mainly using the Firefox flatpak as a convenient way to install and maintain Firefox, it might be sufficient. Also, Firefox should restrict the WebExtension to running the script that calls flatpak-spawn with specific native command you gave it. The concern is that a bug in Firefox might allow arbitrary flatpak-spawn commands to be run (I think).

See https://bugzilla.mozilla.org/show_bug.cgi?id=1621763#c5 for additional details.

[cheako]

Edit: Don't copy/paste from the above comment sed -i 's/org.mozilla.org/org.mozilla.firefox/g' native-messaging-hosts/*.

cheako@mx1:~/.var/app/org.mozilla.firefox/.mozilla$ cat native-messaging-hosts/net.downloadhelper.coapp.json 
{
    "name": "net.downloadhelper.coapp",
    "description": "Video DownloadHelper companion app",
    "path": "~/.var/app/org.mozilla.org/.mozilla/bin/net.downloadhelper.coapp.sh",
    "type": "stdio",
    "allowed_extensions": [
        "weh-native-test@downloadhelper.net",
        "{b9db16a4-6edc-47ec-a1f4-b86292ed211d}"
    ]
}
cheako@mx1:~/.var/app/org.mozilla.firefox/.mozilla$ cat bin/net.downloadhelper.coapp.sh 
#!/bin/bash

touch ~/.var/app/org.mozilla.org/.mozilla/bin/Ihere
exec flatpak-spawn --host /opt/net.downloadhelper.coapp/bin/net.downloadhelper.coapp-linux-64 "$@"
cheako@mx1:~/.var/app/org.mozilla.firefox/.mozilla$ ls bin/Ihere
ls: cannot access 'bin/Ihere': No such file or directory

[cheako]

Also with this ~ expansion is not available, so the whole path must be used. Otherwise it does work, but if it's not setup correctly it's hard or impossible to debug.