Support Firefox in Flatpak

[jim3692]

It's currently impossible to use this extensions with the Flatpak versions of Firefox. That's because Flatpaks do not support native messaging.

That's a known issue for other projects as well, like KeePassXC, and there have been some workarounds we could investigate, for example:

https://discussion.fedoraproject.org/t/how-to-run-firefox-and-keepassxc-in-a-flatpak-and-get-the-keepassxc-browser-add-on-to-work/19452?u=rugk

[illyja]

I've managed to hack together something that seems to work along the lines of the KeePassXC workaround. It's pretty ugly but hopefully it helps anyone trying to do the same, or provides a starting point for a better solution.

I downloaded the source code and extracted the Bash scripts from native/connector and the firefox.json file from native/native-messaging-hosts into ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts (folder does not exist, I created it). I made the firefox.json file to point to pipewire-screen-audio-connector.sh and renamed it com.icedborn.pipewirescreenaudioconnector.json.

Since I messed up the directory structure by putting everything in one folder, I had to modify PROJECT_ROOT in the scripts to point at the script folder instead of the parent folder and also ensure that all paths referencing $PROJECT_ROOT remained correct. This was probably an unnecessary step, and I probably could've done it differently preserving the folder structure, but I didn't play around with it too much.

Next, I added filesystem permissions in Flatseal for Firefox for xdg-run/pipewire-screenaudio and xdg-run/pipewire-0. I then manually created /run/user/1000/pipewire-screenaudio, and fifos and logs subfolders inside of it. This finally allowed the extension to write logs and give me some hint as to what's going wrong, giving into the following error message:

util.sh: line 54: jq: command not found

jq was installed through pacman into /usr/bin, and unfortunately could not be accessed by the scripts when run from inside Firefox's sandbox in Flatpak. Solving this was the ugly part - I ended up having to break it out of the sandbox by replacing every occurrence of jq in the scripts with flatpak-spawn --host jq. This requires modifying Firefox to allow it to talk to org.freedesktop.Flatpak on the session bus. Obviously, this weakens the Flatpak sandbox quite a bit since with the new permission Firefox is allowed to execute arbitrary binaries on the host system using the flatpak-spawn --host.

After I got jq running, it started complaining about some invalid JSON:
jq: parse error: Objects must consist of key:value pairs at line 3054, column 7
I solved this by escaping all instances of pw-dump with flatpak-spawn --host as well.

In retrospect, the first thing I should've tried is copying the jq binary into the ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts folder alongside the scripts, but according to pacman it has a dependency on the oniguruma library so it might not have worked. It also wouldn't be possible to do so for pw-dump.

There are still some unresolved error messages in the logs such as:
Error: "unsupported type PipeWire:Interface:Profiler"
jq: error (at <stdin>:50): null (null) and string ("AudioCallb...) cannot have their containment checked
However, the logs weren't particularly helpful in pinpointing where they were coming from, and after a test everything seemed to be working fine so I left it alone for now.

I'm not particularly happy with this solution, as it sort of brute forces everything and to an extent defeats the point of running Firefox as a Flatpak in the first place. It's also not very general as I had to make Flatpak-specific edits in the scripts to insert flatpak-spawn at appropriate places. For the time being though I'm just happy that I got it to function and I'll have to leave it at that.

[IceDBorn]

We'll soon merge the rust rewrite, someone can look into packaging the native part for flatpak, and then we can work around the manifest problem.

[IceDBorn]

Is anyone interested in implementing? Or should I close the issue?