search

filips123 / PWAsForFirefox

A tool to install, manage and use Progressive Web Apps (PWAs) in Mozilla Firefox
https://pwasforfirefox.filips.si
Mozilla Public License 2.0
2.08k stars 49 forks source link

Flatpak version request - firefoxpwa - native app #142

Open realgrm opened 2 years ago

realgrm commented 2 years ago

Problem Description

This project doesn't work on flatpak version of Firefox

In https://github.com/filips123/PWAsForFirefox/issues/76#issuecomment-962628218 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:

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:

Some search results that may be useful:

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 commented 2 years ago

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

filips123 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 11 months ago

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

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:

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 commented 11 months ago

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 commented 4 months ago

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 commented 4 months ago

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