Flatpak version request - firefoxpwa - native app

[realgrm]

Problem Description

This project doesn't work on flatpak version of Firefox

In #76 (comment) was said that the problem is in the connection between Firefox Extension, installed in the sandboxed environment, and native app (firefoxpwa), installed on the host.

Proposed Solution

Port the native part to flatpak, so both extension and native part would be inside the sandboxed environment.

Some ideas to accomplish it:

• Distribute firefoxpwa as a flatpak plugin for Firefox. Using the Firefox app as runtime to this app.
  Example: com.obsproject.Studio.Plugin.OBSVkCapture uses com.obsproject.Studio as runtime.

• Distribute firefoxpwa as an app and connect with Firefox app through flatpak-spawn. Maybe this isn't the ideal solution, since it would be decreasing the isolation from the system.
  Example: com.ulduzsoft.Birdtray uses .flatpak-spawn to communicate (somehow) with org.mozilla.Thunderbird

• Maybe better solutions arise asking questions for other flatpak developers.

Additional Information

I'm not a developer but I tried to give you the best with the information I have.
Maybe It'd be a good idea to contact the flatpak/Flathub developers:

• Chat - Matrix
• Forum - discourse.flathub

Some search results that may be useful:

• Search for more plugins available on Flathub
• Search for uses of flatpak-spawn inside manifests

flatpak-spawn: flatpak-spawn is a command available to applications inside the sandbox. It runs COMMAND outside the sandbox, either in another sandbox, or on the host

A post was created in the Flathub forum.

[realgrm]

In case of discoverability of the app in case of being implemented as plugin (add-on) in the Gnome Software:
Example: com.obsproject.Studio.Plugin.OBSVkCapture

• search results

• installation

[filips123]

Thank you for providing detailed suggestions on how to implement Flatpak support, but I still have few questions.

Will distributing PWAsForFirefox native app as a plugin allow Firefox to access its Native Messaging manifests? The problem is that they currently need to be present in a specific directory so Firefox can found them. However, there seems to be some ongoing work to support Native Messaging in sandboxed browsers (flatpak/xdg-desktop-portal#655, flatpak/xdg-desktop-portal#705) which will probably help.

Another problem is that the Firefox runtime needs to be modified a bit with some additional files so it can load all modifications. Is it possible to do this as a Flatpak plugin without affecting the main Firefox? Maybe using FUSE filesystem (#67) with Flatpak's Firefox as a lowerdir and some PWAsForFirefox-specific directory as a merged dir? Currently, PWAsForFirefox just downloads its own Firefox runtime from Mozilla and modifies it. However, this means Firefox is duplicated on the system (one system Firefox and one PWA Firefox), and it's probably not a best practice in the Flatpak world.

[VortexAcherontic]

Hello everyone, sorry for bumping this thread without supplying any valuable information but I have a few questions regarding this project.

Had some hopes to get PWA support on Firefox Flatpak working as well and was questioning why is the setup so much different compared to chrome based browsers?
I am just a novice regarding the entire topic and not an expert in any browser so I apologize for my ignorance.
On chrome based browsers (Edge, Chromium, Chrome and even Gnome Web) some can just save the web page as an app and it instantly shows up on your desktop or app launcher also from inside a flatpak sandbox.

Or is it that those browser just spawn a minimal browser window without address bar and significantly less buttons and menus and call it an "app" while this project and Firefox aim to do it right?

Additionally I run an immutable Linux distribution (openSUSE MicroOS) which makes installing packages into the host not impossible but requires extra steps and a reboot.
With the rise of the Steam Deck and SteamOS 3 I see this to be an issue some time soon.
Also on distributions such as Fedora Silverblue and Onyx I foresee this to become a problem.
I would like to see an implementation not requiring additional (unsigned) packages to be install in the host operating system.

Sure I could run Firefox entirely from a Distobox container and also provide the PWA support there but on the other hand this will partially break the desktop integration with the host OS for numerous reasons which are out of scope for this comment.

Anyway the question remains why the Fierfox way of doing this is so much different from the chrome way?

Many thanks for reading this and kind regards,
V.

[filips123]

why is the setup so much different compared to chrome based browsers?

Because Chrome has built-in PWA support while Firefox does not, so this project needs to be installed as a separate extension and additional native program. Just extension is not enough as web extensions do not have the ability to do all things that are needed for PWA support, so an additional native program is required.

[...] while this project and Firefox aim to do it right?

I mean, Chrome has working support for PWAs and I can't say they haven't "done it right". However, this project also offers some features that AFAIK Chromium browsers do not:

• Support for separate profiles (although this is just a by-product of how this project is made). Sometimes it may be more convenient to use the same profile for PWAs and main browsing (as it's done on Chromium), but using separate profiles allows you to do more things that aren't possible on Chromium, like extra customization or using multiple accounts for the same PWA.

• More customization (partially related to the previous topic). This project supports additional configuration abilities that Chromium browsers do not. For example, allowing customization of the browser toolbar, different browser settings for different PWAs, additional addons, etc.

• Better integration with the desktop. Although Chrome and Edge support quite good integration with system (protocol handlers, shortcuts, etc.), last time I checked this was limited to Windows (while on Linux they only created a single desktop shortcut). This project also supports that additional integration on Linux.

I would like to see an implementation not requiring additional (unsigned) packages to be install in the host operating system.

I would also like this, but currently it's impossible because Flatpak does not support the required features to make this work yet. It will probably change in the future because they're working on this on the Flatpak side.

Also, what do you mean by (un)signed packages? Do you mean just publishing this to Flathub or some additional signing certificates, like those on Windows and macOS?

Anyway the question remains why the Fierfox way of doing this is so much different from the chrome way?

TLDR: This project is Firefox extension because Firefox does not have built-in PWAs and an additional native program is required to make it work. Although this causes some problems (like harder installation), it also allows some features that are not available on Chromium browsers (multiple profiles, better customization, better integration). Flatpak is currently not an option because it does not support all required features, but that will probably change in the future.

[VortexAcherontic]

Many thanks for the detail explanation. Now things are a lot more clear to me and I feel like I now properly understand the situation ❤️

Also, what do you mean by (un)signed packages?

Sorry for the confusion here.
I now see, after reading the instructions again, that this was may fault as I downloaded the RPM directly instead of adding the package cloud repo.
Hence my package manager complained about an unsigned RPM to be installed. My bad.

Will keep an eye on the Flatpak side of things for now.

Thank you for your efforts as it does not seem like an easy undertaking getting all this stuff working.

Kind regards,
V.

[ar-lex]

I have some thoughts and questions after experimenting with native app and flatpak version of Firefox.

flatpak-nspawn method works. I just installed the system package (.deb in my case) and then

• created a $HOME/.var/app/org.mozilla.firefox/data/firefoxpwa.sh script with a single command flatpak-spawn --host /usr/libexec/firefoxpwa-connector "$@"
• copied /usr/lib64/mozilla/native-messaging-host/firefoxpwa.json to $HOME/.var/app/org.mozilla.firefox/.mozilla/native-messaging-host/ and changed /usr/libexec/firefoxpwa-connector to full path of the created script.

That's it, everything works as expected - Firefox in flatpak spawns the unconfined binary which generates runtime, profile, .desktop files and icons, then starts that modified Firefox also unconfined.

Then I tried to run the native app confined:

• extracted the contents of a .deb package to $HOME/.var/app/org.mozilla.firefox, specifically
  • /usr/bin/firefoxpwa and /usr/libexec/firefoxpwa-connector to $HOME/.var/app/org.mozilla.firefox/data/bin/
  • /usr/share/firefoxpwa/userchrome to $HOME/.var/app/org.mozilla.firefox/data/share/
  • firefoxpwa.json similarly to flatpak-nspawn method, setting the full path for extracted firefoxpwa-connector
• modified flatpak permissions (I used Flatseal):
  • added filesystem access for xdg-data/applications and xdg-data/icons so that the native app could create .desktop files and icons (which need to be additionally modified, but it's easier anyway)
  • set FFPWA_SYSDATA and FFPWA_EXECUTABLES to full paths accordingly

With these modification the browser extension detects it's native part. The runtime is succesfully downloaded and modified, the app profiles and .desktop files are generated, but the app can't be correctly launched. I used the following command to start the app:

flatpak run --command=/home/<username>/.var/app/org.mozilla.firefox/data/bin/firefoxpwa org.mozilla.firefox site launch <AppID> --protocol

No errors in firefoxpwa logs and no stdout/stderr messages, I only get the following error dialog window:

Failed to read the configuration file. Please contact your system administrator.

As I understood, the _autoconfig.cfg isn't loaded successfully - when I remove general.config.filename from autoconfig.js, there is no such error, but obviously no modifications either. Any assistance welcome.

Regarding other suggestions, particularly flatpak plugin, I don't think that it is the optimal solution. The browser itself has to be modified - Firefox flatpak packaging manifest has to have the definitions for extension file paths and other conventions. This extra complexity IMHO doesn't give any security advantages.

I think there is no need to wait for native messaging portal implementation in flatpak either. Everything we need should be already here. Instead we should aim for the simplicity of VideoDownloadHelper extension approach, which I used as an example for my experiments. If the problem that I encountered would be solved, then the confined native app installation could be as easy as extracting the archive and running the script, everything as a non-privileged user.

[filips123]

As I understood, the _autoconfig.cfg isn't loaded successfully - when I remove general.config.filename from autoconfig.js, there is no such error, but obviously no modifications either. Any assistance welcome.

Well, the first thing to check is whether _autoconfig.cfg has been copied to the Firefox program directory (directly at the root). If it has been, you can launch Firefox with --jsconsole or --jsdebugger and check if there are any related errors, and maybe Flatpak also has some additional logs that you could check. You can also try to remove everything from `_autoconfig.cfg (except the first comment) to see if errors still happen (obviously, modifications then won't apply).

Firefox supposedly loads _autoconfig.cfg from "the top level of the Firefox directory", but maybe it's different in Flatpak. There are some references to Flatpak and Snap in the function that loads autoconfig, so it might be worth checking that. I don't have much time to do this at the moment.

Regarding other suggestions, particularly flatpak plugin, I don't think that it is the optimal solution. The browser itself has to be modified - Firefox flatpak packaging manifest has to have the definitions for extension file paths and other conventions. This extra complexity IMHO doesn't give any security advantages.

I think that the normal browser shouldn't be modified (apart from adding the native messaging manifest), as the PWAsForFirefox runtime should be separate from it. So, it should be downloaded to a separate location (like it's currently normally done) or "linked" to the main Firefox with FUSE/OverlayFS (#214, and I will probably add an option for this in the next versions). Additionally, the user should be able to choose their own Firefox version (or fork), separately from their main Firefox (for example, using normal Firefox for PWAs and LibreWolf for normal, or opposite). Another reason for this is to ensure stability, so the main Firefox wouldn't be affected if PWAsForFirefox broke something.

However, I agree that a plugin isn't optimal for this (also because of the above reasons).

If the problem that I encountered would be solved, then the confined native app installation could be as easy as extracting the archive and running the script, everything as a non-privileged user.

If that script can be made to work, doesn't cause too many problems, and can also address things I mentioned above, I can probably mention it on the documentation page as a workaround. But for the "official" support/package, I'll probably wait until native messaging is properly supported.

---

Ideally, once native messaging is fully supported, I think that PWAsForFirefox should be its own Flatpak (and Snap) package with all the required permissions needed to install web apps (managing desktop entries and icons) and run the Firefox runtime (I guess that means the same permissions as Firefox Flatpak package). Maybe the runtime itself could be in a separate plugin package, so permissions could be separate, and maybe allow users to directly choose alternative runtimes as different plugins (I'm not sure if this is possible). The user should still be able to manually/directly change which runtime to use.

I would also like it if all combinations of (un)sandboxed Firefox and PWAsForFirefox worked. So, unsandboxed Firefox to unsandboxed PWAsForFirefox (this already works), sandboxed Firefox to unsandboxed PWAsForFirefox (this partially works on Snap), unsandboxed Firefox to sandboxed PWAsForFirefox, and sandboxed Firefox to sandboxed PWAsForFirefox. Support between Flatpak and Snap would also be nice. I assume the native messaging portal will handle all of this once it's ready.

[SVTA-OP]

I was using Fedora 39 with Firefox as a flatpak and tried switching to rpm just for FirefoxPWA. It worked flawlessly. I'm not sure if it's the rpm's fault but general performance on Firefox rpm is only a fraction of that of the flatpak version. I got a consistent 1.00 score on MotionMark (using the rpm).

Edit: Forgot to mention that both were running under native wayland.

[filips123]

Maybe RPM version on Fedora is compiled with different compiler optimizations?